Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
smaug---- opened this issue Jul 19, 2016 · 14 comments
Labels
compat Standard is not web compatible or proprietary feature needs standardizing topic: events

Comments

@smaug----
Copy link

smaug---- commented Jul 19, 2016

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
Copy link
Member

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

@zcorpan zcorpan added the compat Standard is not web compatible or proprietary feature needs standardizing label Aug 15, 2016
@annevk
Copy link
Member

annevk commented Oct 25, 2016

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
Copy link
Member

annevk commented Oct 25, 2016

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

@annevk
Copy link
Member

annevk commented Oct 25, 2016

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

@annevk
Copy link
Member

annevk commented Oct 25, 2016

The same goes for #1568. Sigh.

@annevk
Copy link
Member

annevk commented Oct 25, 2016

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----
Copy link
Author

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
Copy link
Member

annevk commented Oct 27, 2016

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
Copy link
Member

zcorpan commented Oct 27, 2016

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
Copy link
Member

annevk commented Oct 27, 2016

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
Copy link
Contributor

@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
Copy link
Member

annevk commented Oct 27, 2016

@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
Copy link
Contributor

dtapuska commented Oct 27, 2016

We have a defaultHandled flag on the event.

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

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

@smaug----
Copy link
Author

ok, sounds like blink's implementation is very close to gecko's.
And it seems to have similar ad-hoc behavior as Gecko that whether something is considered to defaultHandle an event. That is something figure out - what all is "default handled".

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 30, 2024
…=vhilla,dom-core,smaug

The root cause of issue is that the link elements have not yet adopted the
activation behavior defined in the specification. The appropriate  behavior/model
for links is still under discussion, whatwg/html#1576.
For now, we aim for making it consistent with other browsers.

Differential Revision: https://phabricator.services.mozilla.com/D197393
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Feb 1, 2024
…=vhilla,dom-core,smaug

The root cause of issue is that the link elements have not yet adopted the
activation behavior defined in the specification. The appropriate  behavior/model
for links is still under discussion, whatwg/html#1576.
For now, we aim for making it consistent with other browsers.

Differential Revision: https://phabricator.services.mozilla.com/D197393

UltraBlame original commit: ae7ff06eabe7226e2998739a03a0fb63d8e182b7
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Feb 1, 2024
…=vhilla,dom-core,smaug

The root cause of issue is that the link elements have not yet adopted the
activation behavior defined in the specification. The appropriate  behavior/model
for links is still under discussion, whatwg/html#1576.
For now, we aim for making it consistent with other browsers.

Differential Revision: https://phabricator.services.mozilla.com/D197393

UltraBlame original commit: ae7ff06eabe7226e2998739a03a0fb63d8e182b7
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this issue Feb 1, 2024
…=vhilla,dom-core,smaug

The root cause of issue is that the link elements have not yet adopted the
activation behavior defined in the specification. The appropriate  behavior/model
for links is still under discussion, whatwg/html#1576.
For now, we aim for making it consistent with other browsers.

Differential Revision: https://phabricator.services.mozilla.com/D197393
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat Standard is not web compatible or proprietary feature needs standardizing topic: events
Development

No branches or pull requests

5 participants