Moving mouse while having mouse button clicked does not change target (different behavior than in MDN)
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: lukasz-rutkowski, Unassigned)
References
Details
(Keywords: parity-chrome, parity-safari)
Attachments
(1 file)
|
(deleted),
image/gif
|
Details |
firefox.gif
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
Steps to reproduce:
I have selected text in input and ended selection outside of input which according to
https://developer.mozilla.org/en-US/docs/Web/API/Element/click_event should trigger click event on nearest ancestor of mouse click start and end elements.
If the button is pressed on one element and the pointer is moved outside the element before the button is released, the event is fired on the most specific ancestor element that contained both elements.
Codepen to test this behavior (logs in console which element has been targeted):
https://codepen.io/rutek-the-bold/pen/eYBjbJx
Actual results:
Event has been triggered for input instead of of container which contains both input and element where I ended click.
This behavior inconsistent with MDN is present only in Firefox. In Chrome it works as documented.
Expected results:
Event should be triggered for ancestor that contained both elements.
|
||
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
I have reproduced this issue on Windows 10 and Mac OS 11.2 on the latest versions of the 4 channels:
If the user selects part of the "test test test" string and (without letting go of the left-click) hovers outside of the input box (and then lets go of the click), the "<input type="text" value="test test test">" is still seen in the Browser Console instead of
"<div class="main" @click="onClick" x-data="component()">" as seen on in the Chrome browser.
This is not a recent regression considering it reproduces in Nightly v60.0a1.
This also happens for <textarea>, those two seems to implicitly capture the pointer. Additionally, it seems the drag-click behavior of <input> is weird enough, as dragging from the checkbox/radio/number/button does not log any click event while it does on Blink.
What does the spec say, Anne? I guess the Blink behavior is right at least for the latter?
|
||
Comment 3•4 years ago
|
||
There's not a good specification for this, but https://w3c.github.io/uievents/#event-type-click does seem to indicate Chrome and Safari are correct. (Now input and textarea do have special behavior when it comes to selection, but I guess that shouldn't carry over to mouse events...)
I'd like to investigate the latter at least.
|
||
Updated•4 years ago
|
Note for me:
EventStateManager::DispatchClickEventsmust be called to dispatch click events- That's normally called by
EventStateManager::PostHandleMouseUp, but: EventStateManager::PostHandleEventonly calls it whenEventStateManager::EventCausesClickEventsreturns true- And that returns false because
WidgetMouseEvent::mClickCountis 0 - That's set by
EventStateManager::SetClickCountcalled byEventStateManager::PreHandleEvent - The method determines the count by calling
nsContentUtils::GetCommonAncestorUnderInteractiveContent() - And it returns null when
aNode1is<body>andaNode2is<input>, causing mClickCount to be 0.
|
|
||
Updated•4 years ago
|
Unassigning myself from inactive bugs.
Please retriage this one, sorry!
|
||
Updated•2 years ago
|
Description
•