| CARVIEW |
Navigation Menu
-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
script: Implement ToggleEvent and use for <details> element
#40271
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
a6c38dd to
3bae3e2
Compare
ToggleEvent and use for <details> element
mrobinson
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.
Looks good. Just a few nits:
3bae3e2 to
da37e7d
Compare
da37e7d to
c3234b0
Compare
|
I've pushed those changes up, I squashed because of my WebKit brain, is there a preference to squash or push up seperate commites to address comments for servo? |
|
There's no preference. Squashing is fine. I usually squash, but now and then I leave them as separate commits if the original PR is very large and I think it will possibly make a followup review easier. |
Also need to update
|
|
It seems odd that this changes the results of that exclusivity test, I'll take a look, it's possible it previously failed because of the incorrect event type and now it's getting further. |
|
I don't think we support mutually exclusive details elements yet. |
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 nits, mostly curious why parts of the spec aren't implemented. Not sure about the status of this PR though, given that it was scheduled for merge before. So feel free to ignore these for now and fix them in a follow-up PR.
components/script/dom/toggleevent.rs
Outdated
| self.source.as_ref()?; | ||
|
|
||
| if let Some(current_target) = self.event.GetCurrentTarget() { | ||
| return self.source.as_ref().and_then(|source| { | ||
| let retargeted = source.upcast::<EventTarget>().retarget(¤t_target); | ||
| retargeted.downcast::<Element>().map(DomRoot::from_ref) | ||
| }); | ||
| } | ||
|
|
||
| self.source.as_ref().and_then(|source| { | ||
| let document = source.upcast::<Node>().GetOwnerDocument().unwrap(); | ||
| let retargeted = source | ||
| .upcast::<EventTarget>() | ||
| .retarget(document.upcast::<EventTarget>()); | ||
| retargeted.downcast::<Element>().map(DomRoot::from_ref) | ||
| }) |
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.
The spec doesn't state that we should use the owner document if currentTarget is null. Should we instead return None when that's the case? E.g. something like
| self.source.as_ref()?; | |
| if let Some(current_target) = self.event.GetCurrentTarget() { | |
| return self.source.as_ref().and_then(|source| { | |
| let retargeted = source.upcast::<EventTarget>().retarget(¤t_target); | |
| retargeted.downcast::<Element>().map(DomRoot::from_ref) | |
| }); | |
| } | |
| self.source.as_ref().and_then(|source| { | |
| let document = source.upcast::<Node>().GetOwnerDocument().unwrap(); | |
| let retargeted = source | |
| .upcast::<EventTarget>() | |
| .retarget(document.upcast::<EventTarget>()); | |
| retargeted.downcast::<Element>().map(DomRoot::from_ref) | |
| }) | |
| let source = self.source.as_ref()?; | |
| let current_target = self.event.GetCurrentTarget()?; | |
| let retargeted = source.upcast::<EventTarget>().retarget(¤t_target); | |
| retargeted.downcast::<Element>().map(DomRoot::from_ref) |
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.
This is based on the WebKit implementation for command event which uses the same spec language and that in turn was based on I think chromium behaviour. I'll double check if this is erroneous or not.
|
Ah yeah that test uses oldState and newState so was failing and is now timing out. I'll update the expectations file now. |
c3234b0 to
fe343c4
Compare
|
You also need to update
|
fe343c4 to
1735b78
Compare
Signed-off-by: Luke Warlow <lwarlow@igalia.com>
1735b78 to
715b01b
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.
Merging as-is and feedback will be addressed in a follow-up
| let document = source.upcast::<Node>().GetOwnerDocument().unwrap(); | ||
| let retargeted = source | ||
| .upcast::<EventTarget>() | ||
| .retarget(document.upcast::<EventTarget>()); | ||
| retargeted.downcast::<Element>().map(DomRoot::from_ref) |
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 you file a spec bug that this should be updated in the spec given all major browsers implement it this way?
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.
Yeah I'll double check what the state of things is and file an appropriate issue.
Hm I guess this is intermittent flaky :/ Will file an issue |
|
Hopefully the pr to implement that behaviour as a follow up will resolve it quite quickly. |
…ee (#40314) 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 `HashMap` to `Document` and `ShadowRoot` which 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 to `traverse_preorder` in 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 --------- Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
Implement ToggleEvent and use for details element
Testing: Covered by existing WPTs