Issue metadata
Sign in to add a comment
|
mousemove and mouseup events are not sent to an OOPIF when dragging
Reported by
thomasth...@gmail.com,
Aug 20
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0 Steps to reproduce the problem: 1. Load this test page: https://jsfiddle.net/aqh2p69m/2/ 2. Click in the iframe, and while maintaining the button pressed, move out of the iframe. As soon as the pointer exits the iframe, it stops receiving mousemove and mouseup events. What is the expected behavior? Once a button is pressed inside the iframe, the iframe should continue receiving mousemove events up to the next mouseup. This behavior is useful to handle dragging of objects inside the iframe. Firefox, Safari and Chrome before 68 handled this correctly. This still works correctly when the iframe is in the same domain as the parent window, as can be seen there: https://d1o0328zb1mp9s.cloudfront.net/iftest2.html What went wrong? When the iframe is in another domain, Chrome runs it in another process, and it appears this is what is causing the mousemove and mouseup events from being lost when the pointer is outside the iframe. Disabling Chrome's Site Isolation fixes this problem. Did this work before? Yes 67 Does this work in other browsers? Yes Chrome version: 68.0.3440.106 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.13 Flash Version: Shockwave Flash 30.0 r0
,
Aug 21
Able to reproduce the issue on chrome reported version #68.0.3440.106 using Mac 10.13.3, Windows-10 and Ubuntu 17.10 . Note : As the issue got break in branch builds, hence providing manual change-log from omahaproxy. Bisect Information: ===================== Good build: 68.0.3440.40 Bad build: 68.0.3440.41 Change Log: https://chromium.googlesource.com/chromium/src/+log/68.0.3440.40..68.0.3440.41?pretty=fuller&n=10000 Reviewed-on: https://chromium-review.googlesource.com/1112757 creis@ - Please confirm the issue and help in re-assigning if it is not related to your change. Adding 'ReleaseBlock-Stable' label as this is a recent regression. Please feel free to remove if this is not applicable. Thanks...!!
,
Aug 21
M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Merge has to happen latest by 4:00 PM PT Friday (08/24/18) in order to make it to next week stable cut. Thank you.
,
Aug 21
+nasko@, could you ptal as creis@ is OOO. As this is regressed in M68, we're not planning to block M69 stable. Pls target fix for M70. Pls let us know ASAP if there is any concern here. Thank you.
,
Aug 21
,
Aug 21
kenrb@ is the expert on input events with OOPIFs, so assigning it over. We have made some changes in the area, but I'm not certain whether this is expected or not.
,
Aug 21
Yes this is a known problem, tracked under issue 647378 . There was a hack in place in M67 to make mouse capture work but it turned out to break some websites and had to be removed. Right now it works if you are dragging a scrollbar thumb to scroll a frame and the mouse leaves the content area. Also drag and drop works because that is a different code path. Unfortunately it doesn't work if you just hold the mouse down and drag out, which breaks things like auto-scroll while drag-highlighting text. I'll should be able to get back to this problem soon. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Aug 20