Currently, a touchscreen tap on an arbitrary (non-focusable, non-actionable) part of a document results in mouse compatibility events (the classic mouseover > mouseenter > mousemove > mousedown > focus > mouseup > click that follow after the touchstart > touchend) on that particular part of the document that do not bubble as expected; likewise, if an element is currently focused (e.g. a <button>) from a previous tap interaction, this tap outside of it on an arbitrary element also does not send the mouseout > mouseleave > blur event sequence to that focused element (although the focus does seem to move away from the element?). This has been partially documented (through trial and error) here https://www.quirksmode.org/blog/archives/2014/02/mouse_event_bub.html (and I usually mention it in workshops, see https://patrickhlauke.github.io/getting-touchy-presentation/#202) It's likely that this behavior was introduced (together with the old "Making Elements Clickable" technique, which required authors to add empty event onclick handlers to their elements in order to be able to get the mouse compat events on that element itself - see https://patrickhlauke.github.io/getting-touchy-presentation/#204 - which is a behavior that has since been removed in iOS) for performance optimization reasons back in the early days of iOS' event handling. However, this heuristic behavior is currently not documented on developer.apple.com, and it causes problems with event delegation approaches. As a real-world example, I recently spent some time adding iOS hacks to Bootstrap's core scripting to enable things such as dropdowns and tooltips closing when a user taps outside of them (see https://github.com/twbs/bootstrap/pull/22426). The hack involved dynamically adding/removing noop mouse handlers to the child elements of <body>, in order to coax iOS/Safari into bubbling the mouse compatibility events. Admittedly, one could argue that on touch devices one shouldn't rely on event bubbling of mouse compat events, and instead write explicit touchstart/touchend handlers. However, this would make the resulting code far more complex. AND event bubbling as a result of touch happens correctly in all other tested platforms (e.g. Windows 10 Mobile, Android, touch-enabled Windows laptops with Chrome, Firefox). Is it possible to reconsider iOS' current quirky and undocumented event bubbling for mouse events? If the concern was performance, this may have held true back in the days when the behavior was first devised, but on modern/current iOS devices, I'd posit the perf impact may be minimal (particularly since other browsers on other platforms seem to manage this). Failing that, it would still be good to get this documented officially somewhere.
Any chance to at least document this on developer.apple.com?
<rdar://problem/35097817>
Ping to self
Created attachment 330428 [details] Testcase In this simple testcase, bubbling of the synthetic click works fine.
Simon, that test case works because you already have a click handler attached to the elements. The issue does not manifest itself when you have: * target element is a link or form control * target or any ancestor (up to but not including body) has explicit mouse or click handler (even if only empty function) * target or any ancestor (up to and including document) has cursor:pointer https://patrickhlauke.github.io/getting-touchy-presentation/#221 The problem with bubbling/delegation happens when you don't have any of the above. For instance, user taps on a <div> but listens for click on the body (as many event delegation frameworks do). As an example, see https://patrickhlauke.github.io/touch/bubbling/div.html (attached as single file testcase here too)
Created attachment 330463 [details] Test case showing lack of event bubbling
There are more permutations I tested for this at https://patrickhlauke.github.io/touch/ (under the "iOS event bubbling" section)
Created attachment 330475 [details] Click handler on the body This testcase shows the bug.
This happens because Frame::qualifyingNodeAtViewportLocation() doesn't include the body for some reason.
And there's some crazy code that looks at CSS cursor styles to decide which nodes are clickable, which seems bizarre.
This is a really old issue, covered by rdar://problem/5844416. It seems like we're trying to avoid having the tap highlight show up over the entire page, but I think we could fix that without breaking handlers on the body.
*** This bug has been marked as a duplicate of bug 151933 ***