New issue
Advanced search Search tips

Issue 726470 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug

Blocked on:
issue 773348
issue 747465



Sign in to add a comment

change drag-n-drop events to always be relative to the display the cursor is on

Project Member Reported by riajiang@chromium.org, May 25 2017

Issue description

For drag-n-drop events moving from source display (S) to target display (T), all events (mouse press, mouse drag * N, mouse release) are relative to S (uses S's display_id and event location is relative to S's position). This is because we would have a capture after the first mouse press and ozone drm honors capture first. In cash, ash would later do the conversion to send events to the correct display. In mash/mus, window server would do the conversion.

Ideally both ash and WS wouldn't need to do the conversion and ozone drm would take care of finding the right display the cursor is on for drag-n-drop events just like other normal mouse events.
 

Comment 1 by zork@chromium.org, Dec 1 2017

Components: UI>Shell>WindowManager

Comment 2 by sky@chromium.org, Dec 1 2017

Blockedon: 747465
Cc: afakhry@chromium.org
Cc: osh...@chromium.org
This is probably related to issue 773348. Oshima and I previously discussed removing the explicit window capture in ozone, as well as cancel X11 implicit passive grab.
Yes it's related. The current behavior (which has a bug btw) was to mimic the behavior of X's passive grab. Since we own the full stack, we don't have to mimic it any longer.

Comment 6 by ovanieva@google.com, Feb 20 2018

Status: asis (was: Available)
oshima - can we list related bug here? 

Comment 7 by ovanieva@google.com, Feb 20 2018

Owner: osh...@chromium.org
Status: Assigned (was: asis)

Comment 8 by osh...@chromium.org, Feb 20 2018

Blockedon: 773348
Owner: afakhry@chromium.org
Basically we should remove the broken implicit grab in ozone. We can merge 773348 to this, or vice versa.
Labels: -Proj-Mustash Proj-Mash-MultiProcess
Mustash bug scrub: Any updates?
Labels: -Proj-Mash-MultiProcess
There is no longer a blocker for mash work. It's something nice to do, but in no way impacts mash/window-service.

Sign in to add a comment