STR: 1. Load testcase. 2. Click the purple area, *outside the bounds* of the black-bordered rect. EXPECTED RESULTS: An alert should show up. ACTUAL RESULTS: No alert shows up (i.e. the container didn't receive the click)

Here's a reference case, which only differs from the testcase in that it's got a <div> instead of a <button>. It gives "expected results". Hence, this seems to be a button-specific quirk.

Comparison to other engines: * Edge 16, Chrome 65, and Opera (latest as well as 12.15 Presto) all give EXPECTED RESULTS. * Safari 11 clips the overflowing element at the button-boundary, so it's not possible to perform step 2 there. * Firefox (release 57 & nightly 59) gives ACTUAL RESULTS. So we're alone in our behavior here (and our behavior does seem broken, when compared to the reference case). (This is the root cause of https://github.com/webcompat/web-bugs/issues/14817 - that's what prompted this bug report.)

(CC :smaug in case he has any knowledge about this from a DOM/Event-targeting perspective)

(Just wondering, shouldn't this be handled by display list?)

[ Triage 2017/02/20: P3 ]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #4) > (Just wondering, shouldn't this be handled by display list?) Hit-testing is indeed done via a display list, and it's entirely possible that the bug lies in that code somewhere. (But the difference between <button> vs. other elements is interesting & indicates that there's something subtle & button-specific here.)

FWIW something I learnt while digging into some loosely related code is that buttons have custom display-list building code for event delivery: https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/layout/forms/nsHTMLButtonControlFrame.cpp#106 Which is probably related here.

(transferred "see also" link, https://github.com/webcompat/web-bugs/issues/14817 , to now live on the dupe-target bug 1089326)