'run synthetic click activation steps' should look for nearest activatable element

[smaug----]

data:text/html,<a href="data:text/html,link followed">[<input type=button value="test"> ]</a><input type="button" value="click() on the first button" onclick="setTimeout('document.getElementsByTagName(\'input\')[0].click()', 0)">

dispatches click event to a child node of <a>, yet <a> is supposed to be activated.
Per spec that shouldn't happen. I think the spec should be updated to follow the reality.

[cvrebert]

@smaug---- Looks like GitHub butchered the formatting of the code in your comment.

[annevk]

Sigh, I missed this while working click integration and corresponding revamp in the HTML Standard and it wasn't caught during review either.

I don't understand how this works. The input element has activation behavior too, but for some reason we look at its parent anyway. That doesn't always happen. E.g., if the first <input> was type=checkbox (even disabled) the link would not be followed (at least in Chrome).

[annevk]

Also copying @dtapuska @foolip @domenic since they reviewed.

[annevk]

The relevant change to HTML was 7beb920 by the way, and DOM whatwg/dom@cb12fd4.

[annevk]

The same goes for #1568. Sigh.

[annevk]

And #1567. It seems like the model is basically incorrect. Elements presumably have some kind of flag that indicates whether they're currently activatable or some such and that flag is what's checked, not whether they have activation behavior.

[smaug----]

This is a bit messy. In Gecko by default all the default handlers are called, but things like link activation sets an internal 'default prevented' to true and that makes only the innermost link to be followed.
But I can definitely see inconsistencies in the code.

We need plenty of tests here, I'm afraid, and then decide what to spec.

I wonder how other browsers deal with this, since also there in some cases inner most activatable element is triggered (nested ) but in some cases outermost. @dtapuska

[annevk]

Activation behavior elements: link, a, area, label, input, button, menuitem.

Those are the elements we'd need to test with and for input and button we should also test their various type attribute values, in particular those that have some kind of effect.

(It seems for link, a, area we only define them as having activation behavior when they create a hyperlink. That's not correct per how activation behavior is defined today, so that needs to be cleaned up too.)

[zcorpan]

IIRC link only has an activation behavior in Gecko, not in other browsers...

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4615

Well it seems WebKit now follows the link when clicking it, but Chromium/Edge 13 don't.

[annevk]

Let's make that a separate issue if we even want to change that. Excluding link from the tests seems fine, it's not important for deciding what the model should be.

[dtapuska]

@smaug---- In Blink we have the concept of default event handlers. And the default event handlers execute up the event path (provided the event bubbles) until one returns that it can handle the event.

I agree only having one activation target doesn't actually convey what is implemented.

[annevk]

@dtapuska how is "can handle the event" implemented? The specification looks for "has activation behavior", but it sounds like it's a little more involved.

I agree only having one activation target doesn't actually convey what is implemented.

I'm not sure what this means. It doesn't sound like the model we ended up specifying anyway.

[dtapuska]

We have a defaultHandled flag on the event.

Ultimately in Blink's implementation we have these steps after 13.

13. Set Event target to be target
14. Set event’s eventPhase attribute to NONE.
15. Set event’s currentTarget attribute to null.
16. If Event not defaultPrevented
    For each tuple in event’s path, in order:
    1. Invoke defaultEventHandler
    2. If Event defaultHandled break;
17. Unset event’s dispatch flag, stop propagation flag, and stop immediate propagation flag.