User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre try the demo works in webkit opera and ie don't know if this behavior is standard, but i think mozilla can do an exception in this case its impossible to manage mouse over/out events for example in ballons, dropdowns does not works with position relative too thank you Reproducible: Always

sorry

* sorry for the multiple posts, and sorry for the error in the summary, ive fixed it (the summary, not the bug, that is still unresolved) try the demo!

This doesn't work in IE 6-8. "bug demo" doesn't work at all in IE

Sorry, intended to say: "valid testcase" works in IE 6-7, not in IE 8 "bug demo" doesn't work at all in IE

actually it works in every version of IE, included 9

We pretty definitely do not allow kids of a button to be directly targeted by events; only the area of the button itself can get events for the button. I believe we had to do that for website compat, in fact. roc might know more, though.

hi boris, what the spec says? what do you mean for "compact" anyway i see, if the positioned child element is positioned over the button it will works, but only the event attached to the button itself, not the event of the inner content(s) <button> <span style="position:relative;top:1px;" onclick=" alert('this will never works!');"> Test Me </span> </button>

This would be pretty easy to fix, I'm just not sure what the right fix would be. Allow out-of-flow descendants of <button> to receive their own events?

hi robert i think the event propagation should work as normal, it's just my opinion for example in bubbling mode, if i click the inner child the event should works on the inner child itself and retargeted on <button> too and in capturing too... same thing! thank you

> hi boris, what the spec says? Nothing. > i think the event propagation should work as normal, Giorgio, this isn't a propagation issue. It's a targeting issue. The content inside the <button> is treated as transparent when the event target is being determined. If you have something on the page under it, that something will get the event instead. No spec defines event targeting at the moment.

uhm... so the targeting is not resolved by the dom? for example parentNode.initEvent in bubbling? i am not in confidence with mozilla's internals but i don't understand why <button> is different from others elements.. ok is system specific element, but it is a "system specific element" also on other browsers, and on other browsers works good! in my example if you change the tagName from <button> to <button2> it works exactly like i expected inside buttons any children pointer event is totally invisible (css events too :hover for example) there's some problem to do what others browsers do? thank you both boris and robert for your partecipation

> uhm... so the targeting is not resolved by the dom? No. In DOM terms, determining what node to call dispatchEvent on when you click is not defined in any spec.

ok but the common behavior in targeting is parentNode in bubbling, children in capturing anyway i hope to know if you will fix this or not... i don't want absolutely to hurry you developers, i want to know if it is possible to fix it, otherwise i will need a custom button workarounds are welcome :) thank you!

ah... feel free to set a better summary for this bug, english is not my primary language again thank you

news?

I confirm we reproduce this bug on Firefox 25 Nightly: http://hg.mozilla.org/mozilla-central/rev/b48e06621dc9, and this bug is not reproducible on IE5..10, Chromium 30, Safari 5. I seem this is web compatibility issue. So What is this bug status?

Here is a jsfiddle with the problem: http://jsfiddle.net/VRV2d/6/ It fails in Firefox both desktop and android, IE 9, 10 and 11 (didn't try I8-). It works in Chrome (desktop and android), Android Browser and IOs (5 and 7 at least). Apart from not propagating js events it also doesn't change apply css pseudo states like hover. I really think that this should propagate events like any other element since I tend to see the button as just an specialized container like a div or a span but with some styling and state.

Whoever fixing this bug please be advised Gaia Keyboard currently rely on this bug to access the "correct" |evt.target|. I will file a bug to fix it. Adding super easy URL for STR: Expected: console logging two lines, span and button. Actual: console logging callback on button only.

Actually, the specification for button [1] say its content model is phrasing content without interactive content. Interactive content [2] is intended to trigger click and other events. So, in theory, inside a button, positioned or not, it should be only phrasing content with no interaction so the implementation could be considering all the inner elements are not clickable. [1] http://www.w3.org/TR/2011/WD-html5-20110405/the-button-element.html#the-button-element [2] http://www.w3.org/TR/2011/WD-html5-20110405/content-models.html#interactive-content

(In reply to Salvador de la Puente González [:salva] from comment #22) Interesting, thanks for looking up the spec. I think you meant to point to the latest, which have just reached CR (\o/): http://www.w3.org/TR/html5/forms.html#the-button-element http://www.w3.org/TR/html5/dom.html#interactive-content-0 But neither the working draft nor the CR spec states anything about amendment to the existing event dispatching model, it just said there should be no interactive content inside <button>. That said, I agree with you this is an ambiguity, or even a conflict between two specs (spec for <button> and spec for DOM event dispatching).

> Actually, the specification for button [1] say its content model That's an authoring requirement, not a UA requirement. That is, a button that contains interactive content would fail an HTML validator, but that says nothing about how UAs should handle the markup. Furthermore, "interactive content" is not an arbitrary definition. It's simply the list of tag names at http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#interactive-content-2 It's not clear to me whether there are now normative user agent requirements here... > I think you meant to point to the latest, The right thing to point to is http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-button-element because that's what we use as an implementation target, not the W3C fork. > or even a conflict between two specs There is no conflict, just like there is no conflict between the HTML spec saying that <span> is not allowed to contain <p> as an _authoring_ requirement while the HTML parser is specified to parse <span><p></p></span> and produce a DOM tree with a span containing a <p>.

So, we had the first real-world breakage caused by this bug, and I did some research. Chrome, Safari, and Edge seem to treat content inside the button as additional click targets, and we seem to be the only browser not doing so. Flagging this with webcompat? so we can have a chat the next time we look at these issues.