change drag-n-drop events to always be relative to the display the cursor is on |
|||||||||
Issue descriptionFor 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.
,
Dec 1 2017
,
Jan 2 2018
,
Jan 2 2018
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.
,
Jan 3 2018
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.
,
Feb 20 2018
oshima - can we list related bug here?
,
Feb 20 2018
,
Feb 20 2018
Basically we should remove the broken implicit grab in ozone. We can merge 773348 to this, or vice versa.
,
Aug 14
Mustash bug scrub: Any updates?
,
Aug 14
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 |
|||||||||
Comment 1 by zork@chromium.org
, Dec 1 2017