-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
script: Enforce exclusivity between <details> elements in the same tree #40314
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
Conversation
|
🔨 Triggering try run (#18975276824) for Linux (WPT) |
|
Test results for linux-wpt from try job (#18975276824): Flaky unexpected result (12)
Stable unexpected results that are known to be intermittent (24)
Stable unexpected results (2)
|
|
|
|
🔨 Triggering try run (#18976979696) for Linux (WPT) |
tests/wpt/meta/html/semantics/interactive-elements/the-details-element/name-attribute.html.ini
Outdated
Show resolved
Hide resolved
6772938 to
b3e7521
Compare
|
Test results for linux-wpt from try job (#18976979696): Flaky unexpected result (17)
Stable unexpected results that are known to be intermittent (22)
|
|
✨ Try run (#18976979696) succeeded. |
|
Does this account for situations when the details elements are nested but have the same name? I seem to recall that other browsers added handling for that. Perhaps that's not specced though? |
I can't test it right now but I don't see why it wouldn't work with the current implementation. The details content is still in the same tree (even if its slotted in a internal shadow tree for |
<!DOCTYPE html>
<details id="outer" name="foo">
<details id="inner" name="foo"></details>
</details>
<div id="host"></div>
<div id="container"></div>
<script>
let inner = document.getElementById("inner");
let outer = document.getElementById("outer");
outer.open = true;
inner.open = true;
console.log(outer.open);
console.log(inner.open);
</script>This logs |
b3e7521 to
9b1a7d4
Compare
|
🔨 Triggering try run (#19022088053) for Linux (WPT) |
|
Test results for linux-wpt from try job (#19022088053): Flaky unexpected result (21)
Stable unexpected results that are known to be intermittent (18)
|
|
✨ Try run (#19022088053) succeeded. |
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
9b1a7d4 to
0b38a60
Compare
TimvdLippe
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some small comments, but overall LGTM!
| document | ||
| .details_name_groups() | ||
| .unregister_details_element(old_name, self); | ||
| if matches!(mutation, AttributeMutation::Set(_)) { | ||
| document | ||
| .details_name_groups() | ||
| .register_details_element(self); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we reduce duplication here by retrieving the relevant details_name_groups from the rootnode and then perform the steps? Given that both return RefMut, I would think that it should be possible to do that, is it not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that will work because something has to be keeping the RefMut alive and that's either a shadow root or a document. I don't see a way to generalize here.
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
Within the same tree, only one
<details>element with the same name may be open at a time. Before this change, this invariant was not enforced.I've added a
HashMaptoDocumentandShadowRootwhich maps from a name to the a list of details elements with the same name. This map allows us to find conflicting details elements without having to traverse the whole tree. Of course this only works when the tree is a document tree or a shadow tree, so we still have to fall back totraverse_preorderin some cases (which I believe to be uncommon).This is ready for review, but I'd like to wait until #40271 is merged to not cause unnecessary merge conflicts.
Testing: New web platform tests start to pass