'pointerout', 'pointerenter' and 'pointerleave' events incorrectly fired during pointer capture
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Tracking
()
People
(Reporter: aleksandar.xyz, Assigned: edgar)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Steps to reproduce:
Capture pointer using setPointerCapture on pointerdown event. For example:
let capturing;
element.addEventListener( 'pointerdown', ( event ) => {
element.setPointerCapture( event.pointerId );
}, false );
Here is a working demonstration:
https://jsbin.com/vaxiruhapi/4/edit?js,output
It could be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1078327 but in regards to pointer leaving the window.
Actual results:
I you move the cursor while dragging out of the browser window, 'pointerout', 'pointerenter' and 'pointerleave' will incorrectly fire.
Expected results:
The events should not fire until the mouse/pen button is released
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
Assignee | |
Updated•4 years ago
|
|
||
Comment 2•4 years ago
|
||
This isn't reproducible on Windows nor Ubuntu. Anne, could you try reproducing this on macOS?
|
||
Comment 3•4 years ago
|
||
I can reproduce (I have Fission enabled though). If I hold the pointer down in the orange square, then drag it outside the window, the number keeps updating until I'm outside the window at which point it logs pointerleave.
|
|
Assignee | |
Comment 5•4 years ago
|
||
I can reproduce on Mac, too. The pointer capture stops after mouse moves outside the browser window, I guess it might be a bug on widget code, or Mac have a different behavior than other platform.
|
|
||
Comment 6•4 years ago
|
||
Note that neither Chrome (on macOS) nor Safari behave like Firefox, so it does not seem like a platform difference in that sense.
|
|
Assignee | |
Comment 7•4 years ago
|
||
(In reply to Anne (:annevk) from comment #6)
Note that neither Chrome (on macOS) nor Safari behave like Firefox, so it does not seem like a platform difference in that sense.
I meant our code for event handling is generic for all platforms, but the issue happens on Mac only, so it might because Mac has some different behavior at the widget layer, e.g. the widget event order/timing is different or such, and we don't handle it well. But it is just a guess, I need to take a look closely.
|
|
Assignee | |
Comment 8•4 years ago
|
||
In Mac OS, while mouse leaves tracking area it would generate eMouseExitFromWidget even during the drag, and we don't do any special handle for that, so you would see those event bubble up to the web content. Chrome seems only handle mouse left button correct, if you test with mouse right button, you would see same issue on Chrome. I tested various cases on Safari, all of them works well.
In Window platform, we would setup capture while mouse button is pressed, see https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/widget/windows/nsWindow.cpp#4454-4471.
Not sure how Linux platform works.
|
|
Assignee | |
Comment 9•4 years ago
|
||
(In reply to Edgar Chen [:edgar] from comment #8)
Not sure how Linux platform works.
Linux seems to have the same issue.
|
|
Assignee | |
Comment 10•4 years ago
•
|
||
Not sure if we should handle this in Widget, like Chrome does, https://source.chromium.org/chromium/chromium/src/+/master:ui/base/cocoa/base_view.mm;l=166-172;drc=3930cf3f0e2404a517b4580b21e598a3fc648ff0. But this seems to also happen on Linux, I guess we could try to handle this on EventStateManager, for example, ignore eMouseExitFromWidget or convert it to eMouseMove during pointer capture.
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
| Comment hidden (spam) |
Description
•