Bug 174564 - click event does not dispatch to parent when child target stops hit testing after mousedown
Summary: click event does not dispatch to parent when child target stops hit testing a...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
Keywords: InRadar
Depends on:
Blocks: 174565
  Show dependency treegraph
Reported: 2017-07-16 06:55 PDT by Antoine Quint
Modified: 2017-07-17 12:14 PDT (History)
6 users (show)

See Also:

Testcase (433 bytes, text/html)
2017-07-16 06:55 PDT, Antoine Quint
no flags Details
Patch (6.34 KB, patch)
2017-07-17 10:50 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Quint 2017-07-16 06:55:29 PDT
Created attachment 315605 [details]

See the attached test case. It has a <div> with a child <div>, both the parent and the child have the same initial, overlapping bounds. The parent shows an alert when receiving a "click" event, the child shrinks itself to 25% of its size using a "transform: scale(25%)" style when the ":active" pseudo-class matches. If you click in the center of the parent, the "click" event is dispatched. If you click on the left, top, right or bottom of the parent, there is no "click" event dispatched, seemingly because the original event target, the child, is no longer hit-testing by the time the mouse pointer is released.

Firefox behaves the same as WebKit, but Chrome dispatches the "click" event in all cases, which seems correct to me.
Comment 1 Radar WebKit Bug Importer 2017-07-16 06:55:51 PDT
Comment 2 Antoine Quint 2017-07-16 07:00:11 PDT
This causes https://bugs.webkit.org/show_bug.cgi?id=174565.
Comment 3 Antoine Quint 2017-07-16 07:29:31 PDT
If/when this gets fixed, we should remove the workaround for https://bugs.webkit.org/show_bug.cgi?id=174565.
Comment 4 Simon Fraser (smfr) 2017-07-16 21:25:55 PDT
So the question is whether :active style is applied before or after the click? :active applies at mouseDown time, and click fires after mouseDown/mouseUp, so I think our behavior is correct.
Comment 5 Chris Dumez 2017-07-17 09:59:09 PDT
In EventHandler::handleMouseReleaseEvent(const PlatformMouseEvent&), we end up with targetNodeForClickEvent() with a mousePressNode being the child and a mouseReleaseNode being the parent node. The logic inside targetNodeForClickEvent() returns nullptr in this case so we do not fire a click event.

It sounds like we would want to fire the click event at the mouseReleaseNode instead? I'll look up the spec and check the blink code as well.
Comment 6 Chris Dumez 2017-07-17 10:02:26 PDT
From https://w3c.github.io/uievents/:
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.

So it sounds like we are supposed to fire the click event at the nearest common ancestor. In the test case, that would be the parent node.
Comment 7 Chris Dumez 2017-07-17 10:50:34 PDT
Created attachment 315677 [details]
Comment 8 WebKit Commit Bot 2017-07-17 12:14:15 PDT
Comment on attachment 315677 [details]

Clearing flags on attachment: 315677

Committed r219568: <http://trac.webkit.org/changeset/219568>
Comment 9 WebKit Commit Bot 2017-07-17 12:14:17 PDT
All reviewed patches have been landed.  Closing bug.