If a preventDefault was called on a 'mousedown' event in an iframe, its corresponding 'mouseup' event isn't fired when it happens outside of the iframe.
Reported by
imanbell...@gmail.com,
Dec 14
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: In the attached index.html page: 1. Press the mouse button (any button) inside the iframe 2. Move the mouse outside the iframe while maintaining the button pressed 3. Release the mouse button outside the iframe What is the expected behavior? - 'mousemove' events should continue to fire from within the iframe - A 'mouseup' event should be fired from within the iframe What went wrong? - 'mousemove' events are fired from the main page only, and not from within the iframe - The 'mouseup' event is fired on the main page, not from within the iframe. Did this work before? N/A Does this work in other browsers? No The issue is present in IE 11, but not in Firefox 60.2.2esr. Chrome version: 71.0.3578.98 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Additional information: if you only call preventDefault on a middle button 'mousedown' (uncomment the if statement in the code sample), and do the following steps: 1. Press the middle button inside the iframe, then press the left button (still inside the iframe) 2. Move the mouse outside the iframe while maintaining both buttons pressed. 3. Release the middle button outside the iframe. In this scenario, the middle button 'mouseup' event is correctly fired from inside the iframe, even though preventDefault was called when the middle button was pressed. Why is that? (this correct behavior is common to Chrome, IE 11 and Firefox 60.2.2 ESR)
,
Dec 17
,
Dec 17
Able to reproduce the issue on chrome reported version# 71.0.3578.98 and on latest chrome# 73.0.3642.0 with sample file and steps mentioned in comment# 0 using Mac 10.14.1, Windows-10 and Ubuntu 17.10. As this issue is seen from M-60(60.0.3112.0), hence considering this as Non-Regression and marking it as Untriaged. Thanks!
,
Dec 20
The behavior seems expected as we don't capture mousemove and up events when preventDefault And I can't repro the middle button case. The behavior feels same as the left button case.
,
Dec 20
,
Dec 21
Hi, What is the reasoning behind this chosen behavior? The use case I have is a 3D WebGL viewer inside an iframe: preventDefault needs to be called for mousedown events in order to implement 3D manipulations with the mouse in the viewer. The issue is that if a manipulation starts inside the iframe with a mousedown, and finishes outside the iframe with a mouseup, we have no way of knowing that the manipulation should end. So when the mouse re-enters the iframe, it's stuck in the manipulation. There must be other similar use cases. As for the additional scenario, maybe I didn't explain it well. This is basically the scenario: - preventDefault is called only on the middle button mousedown. - MiddleMouseDown, LeftMouseDown (without releasing the middle button), MouseMove outside iframe (with both buttons pressed), MiddleMouseUp. In this case, even though the middle mouse down was preventDefaulted, the middle mouse up is correctly fired from inside the iframe. My point was that it doesn't seem consistent with the main behavior choice (i.e. not firing mouseup if the mousedown was preventDefaulted). |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by phanindra.mandapaka@chromium.org
, Dec 15