1229143 - Not receiving click event on the common ancestor of two elements

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect, P5)

Description

[Navid Zolghadr]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Steps to reproduce:

Here is a sample page to show the click behavior when mouse is pressed in the blue box and released on the green box the yellow box should get the click event.

http://output.jsbin.com/wegiti/4/


There was another issue that was reported against Chrome

https://code.google.com/p/chromium/issues/detail?id=543776

However, the behavior of sending click event to the nearest inclusive common ancestor of mouse pressed and mouse released elements is consistent with the spec and also with what IE and Safari do. So I was wondering if that is something that should be fixed in FF.




Actual results:

Click event is not sent to the common ancestor.


Expected results:

Click event should have been sent to the common ancestor.

Comment 1

[Rick Byers]

Seems the UI Events spec isn't too precise about this, but here's what it currently says:

https://w3c.github.io/uievents/#events-mouseevent-event-order

"Each implementation will determine the appropriate hysteresis tolerance, but in general should fire click and dblclick events when the event target of the associated mousedown and mouseup events is the same element with no mouseout or mouseleave events intervening, and should fire click and dblclick events on the nearest common inclusive ancestor when the associated mousedown and mouseup event targets are different."

Olli, thoughts?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

What we do is what the spec used to say (mousedown/up on the same element), and at some point it changed to have "the nearest common inclusive ancestor". I don't know why.
However it feels wrong if you mousedown on element x and then remove some large subtree and do mouseup, and click ends up to some totally unrelated element.

We could probably follow what the current spec say, assuming other browsers do it too - so
mouseout events disable click.

But http://output.jsbin.com/wegiti/4/ shows that blink does something else - mouseout doesn't seem to prevent click. Would blink be willing to follow the spec?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Oh, perhaps I misinterpreted the spec.

The testcase does show really odd behavior in blink, but gecko is probably broken in other ways, and the spec too.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that mouseout shouldn't cancel click event since we (should) allow this operation:

1. mousedown in a button
2. move mouse cursor outside the button
3. move mouse cursor into the button again
4. mouseup in a button

Then, the button should be clicked.

But I'm not sure if click event should be fired on common ancestor element. I feel it's odd that when mousedown in element X, move into element Y and mouseup, then, element Z which is common ancestor of X and Y becomes active.

And I think that the reporter's expected behavior needs to compute common ancestor node and observe all nodes between root node and the element X during mouse button is pressed. This is a little bit expensive only for the edge use cases. So, I don't think that it's reasonable behavior. However, it seems that for shadow DOM, is similar behavior necessary with Shadow DOM? (See also bug 655461)

Comment 5

[Rick Byers]

> Would blink be willing to follow the spec?

We're definitely willing to change blink here (when it'll increase expected interoperability without causing much of a web compat problem of course).  We started looking at this issue precisely because we thought the naive "common ancestor" algorithm wasn't great.  I don't personally have a better suggestion though.  If this is already what most web developers expect then it's probably best not to deviate from that much.  If there are little tweaks we can make to reduce unintended 'click' events without breaking stuff, then that's great.

> I feel it's odd that when mousedown in element X, move into element Y and mouseup, then, element Z which is common ancestor of X and Y becomes active.

By "becomes active" do you just mean receives a "click"?  This should have nothing to do with the :active state IMHO.  This isn't completely crazy to me.  If the user hadn't moved their mouse off the element, the ancestor would have got the event when it bubbled up, no real reason that movement inside the element should change whether or not the ancestor gets an event.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(I wasn't talking about :active but "receives click")
Hmm, right, I guess I could live with that in case mousedown's target is removed from document.

But the spec is too vague here.

Does "should fire click and dblclick events on the nearest common inclusive ancestor when the associated mousedown and mouseup event targets are different" actually mean mouseouts between mousedown/up are ok? If so, why is " the event target of the associated mousedown and mouseup events is the same element with no mouseout or mouseleave events intervening" needed?

And at which point is 'inclusive ancestor' calculated? Does UA need to store event target chain when mousedown is dispatched and then compare it to the event target chain of mouseup?
What if mousedown's target is moved from document A to document B, and mouseup happpens over target when it is in document B.
document B wouldn't have got mousedown, but gets mouseup and click?


And the spec says also "The click event MAY be preceded by the mousedown and mouseup events on the same element, disregarding changes between other node types (e.g., text nodes)."
That requires mousedown/up on the same element. So the spec contradicts itself.

Comment 7

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Comment 8

[Edgar Chen [:edgar]]

I think this is fixed by bug 1089326 where we start firing click event on closest ancestor of mousedown/mouseup targets.