-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Comments
@smaug---- Looks like GitHub butchered the formatting of the code in your comment. |
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 |
The relevant change to HTML was 7beb920 by the way, and DOM whatwg/dom@cb12fd4. |
The same goes for #1568. Sigh. |
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. |
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. 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 |
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.) |
IIRC 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. |
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. |
@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. |
@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'm not sure what this means. It doesn't sound like the model we ended up specifying anyway. |
We have a defaultHandled flag on the event. Ultimately in Blink's implementation we have these steps after 13.
|
ok, sounds like blink's implementation is very close to gecko's. |
…=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
…=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
…=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
…=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
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.
The text was updated successfully, but these errors were encountered: