Change when button has activation behavior about html HOT 7 OPEN

#1567 (comment) has a suggested way to write this down a lot clearer. And then the outcome needs to meet these criteria:

• well-defined
• tested
• web compatible.

from html.

2. button that has a `popovertarget`
   
   * `<a href="#link"><button popovertarget="foo">click</button></a><article id="foo">article</article>` In Chrome but not in Firefox, clicking the button will activate the popover and follow the link. This corresponds to both the link and button being activation target. I'm unable to test on Safari.

I update the test a bit,

data:text/html,<a href="javascript:alert('link%20followed');"><button popovertarget=foo>click</button></a><div id=foo popover>popover</div>

Safari behaves the same as Chrome.

from html.

<input type=button> has a similar issue,

Test with

data:text/html,<a id=link href="javascript:alert('link%20followed');"><input type=button value=click></a>

a's activate behavior is triggered.

And test with input type button with popovertarget

data:text/html,<a href="javascript:alert('link%20followed');"><input type=button value=click popovertarget=foo></a><div id=foo popover>popover</div>

Chrome and Safari triggers both a's activate behavior and the popover.

from html.

Another issue

data:text/html,<a href="javascript:alert('link')"><form action="javascript:alert('submit')"><input type=submit onclick="this.type='button'"></form></a>

According to the spec, the input element is activation target. But Firefox as well as Chrome trigger the link. Introducing a has-activation-behavior algorithm as described in #1567 (comment) probably would not mitigate this.

from html.

@vinhill It seems a simpler version of that would be data:text/html,<form%20action="javascript:alert('submit')"><input%20type=submit%20onclick="this.type='button'"></form>. Something with activation behavior makes itself ineligible for activation behavior (and therefore we end up looking at the parent in the complicated case). But yeah, addressing that might require some heavier restructuring. And it's definitely broken in both its simple and complex forms today.

from html.

Both of my proposed solutions are probably not a good idea.

• Idea 1, introduce a has activation behavior algorithm. This would change the behavior of buttons changing their type on click in a way that is visible to the web.
• Idea 2, have buttons activate ancestor links. I think this is a bit ugly and more importantly, elements in the event chain between button and anchor cannot stop the navigation through preventing default.

I read the code from Blink and WebKit, maybe we can align the specification to their implementation through the following changes

• In dispatch, activationTarget becomes legacyActivationTarget and is only used for legacy-pre- and legacy-canceled-activation behavior
• Introduce a new default handled flag for events
• After step 11, walk the event's path and invoke each element's activation behavior until the event is canceled or default handled
• The activation behavior algorithms are changed to set the default handled flag accordingly.

For comparison, here is the corresponding code for default handling the event in Blink and WebKit.

An open question for me is whether popover should cause the default handled flag to be set. It doesn't seem to be the case in Chromium (see here), but as stated above, I'm unsure if this is intended.

from html.

cc @rniwa @nt1m @mfreed7

from html.