Drag over div over iframe does not receive dragover events
Reported by
i...@vivaldi.com,
Jan 19
(3 days ago)
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Vivaldi/2.2.1388.37 Steps to reproduce the problem: 1. Open the attached file. It contains a drag-drop example with an absolutely positioned div on top over iframe. 2. Drag the green "Drag me!" element over the yellow text. What is the expected behavior? When the drag object over the yellow div, the document should receive dragover events and continue to report their position. What went wrong? The dragover events are only received and reported when the drag object is outside of the iframe. When it is dragged into iframe, no events are received even if the object over the yellow div positioned on top of the iframe. Did this work before? Yes Chromium 71 Does this work in other browsers? Yes Chrome version: 72.0.3626.55 Channel: beta OS Version: Ubuntu 18.04 Flash Version: It seems this is regression due to enabled VizHitTestDrawQuad feature. In particular, the drag API calls into RenderWidgetHostInputEventRouter::GetRenderWidgetHostAtPoint(). That function calls FindViewAtLocation(). In the example that function return the view for the iframe and sets should_query_view to true when the mouse is over the div positioned over the iframe. But GetRenderWidgetHostAtPoint() ignores the flag and incorrectly returns the child view, not the view for the parent.
,
Jan 19
(3 days ago)
Issue 923652 has been merged into this issue.
,
Jan 19
(3 days ago)
pointer-events:none is not helpful at all as the iframe needs to react to the dragover events.
,
Jan 20
(2 days ago)
,
Yesterday
(43 hours ago)
Able to reproduce the issue on the reported chrome 72.0.3626.55, chrome stable 71.0.3578.98 and canary 73.0.3678.0 using Ubuntu 17.10. Below is the Manual bisect (got all bad builds while running tool bisect) information for same. Note: Issue not seen on Mac and Windows. Bisect Info: ================ Good build: 71.0.3554.0 Bad build: 71.0.3556.0 CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/71.0.3554.0..71.0.3556.0?pretty=fuller&n=10000 Suspect: https://chromium-review.googlesource.com/c/chromium/src/+/1225931/ Reviewed-on: https://chromium-review.googlesource.com/1225931 Daniel Cheng: Please confirm the issue and help in re-assigning if it is not related to your change. Adding RBS label for M-71 feel free to change it if not required. Thanks!
,
Yesterday
(43 hours ago)
,
Yesterday
(38 hours ago)
We're not planning any further M71 releases, pls target fix for M72 if this is super critical.
,
Today
(10 hours ago)
,
Today
(9 hours ago)
Per comment #0, this was working in M71. But per bisect provided at #5, this is broken in M71. Pls confirm this is M71 or M72 regression.
,
Today
(9 hours ago)
I'm guessing this is because VizHitTestDrawQuad was/is an experiment; it was changed to default on in https://chromium.googlesource.com/chromium/src/+/fda3ed7f1e8a2bf02e29b9c4c88e6a6fbae7b8ef. If I disable both VizHitTestDrawQuad and VizDisplayCompositor, then the dragover events do fire. I'm removing Android since SiteIsolation isn't enabled by default there. I'm not sure if this is going to be easy/possible to fix, especially in time for M72. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by woxxom@gmail.com
, Jan 19 (3 days ago)