If a user clicks on <button><i>hello</i></button>, does the event bubble to the document?

[domenic]

https://jsfiddle.net/2xc8w552/ for the test case. https://bugs.chromium.org/p/chromium/issues/detail?id=588760 for some more background.

The spec says

A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element.

Is this supposed to mean "the event path computation, when it encounters a disabled element, should cut itself short and stop getting a parent"? This would imply clicking on the <i> element should not bubble to the document.

Or is it just, "when the event target is a disabled element, don't fire click events"? In which case the <i> is not a disabled form control, so the event should probably propagate as normal.

I think it's the former, but it would be better to phrase it in terms of the new event path semantics. @annevk, willing to give it a shot? (There are a lot of similar phrases; search for "prevent any click events".)

[annevk]

It sounds like the latter to me. @smaug---- can confirm.

If if is indeed the latter, I think this would need to be defined as part of the specification that defines hit testing, when mouse events are dispatched and how, etc.

[smaug----]

Clicking on in Gecko dispatches the event to the (since that is what HTML4 wanted, at least based on certain interpretation: is just using its content for rendering). So Gecko needs to just check whether is disabled, and if so, not process click. (in other words while creating event path, HTMLButtonElement tells that it can't handle the event and that it also doesn't have any parent targets).

If we don't want that

behavior, then we need to create the path and while creating it
each target needs to have a way to say whether event can be dispatched.
That isn't quite what http://mxr.mozilla.org/mozilla-central/source/dom/html/HTMLButtonElement.cpp?rev=e8c7dfe727cd&force=1#213 is about, since that doesn't affect to already created path (which just happens to be empty in this button case in Gecko).

[domenic]

Clicking on in Gecko dispatches the event to the

Hmm. I don't think that interpretation is supported by the spec at all. So if I addEventListener on the , it will never be called?

I think the preferable solution which preserves Gecko's behavior (in most cases) but also the spec intent is my "the event path computation, when it encounters a disabled element, should cut itself short and stop getting a parent"

If if is indeed the latter, I think this would need to be defined as part of the specification that defines hit testing, when mouse events are dispatched and how, etc.

I don't think there's any need to push speccing this into the indefinite future. It can be accomplished easily by clarifying the spec's existing sentence to talk more explicitly about event paths and get-the-parent.

[smaug----]

Hmm. I don't think that interpretation is supported by the spec at all. So if I addEventListener on the , it will never be called?

Right. The spec doesn't define hit testing. And in Gecko hit testing here happens to catch <button> and not <i> here.