-
Notifications
You must be signed in to change notification settings - Fork 44
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
Extend locateNodes with a locator to get navigable's container element #811
Conversation
b6e0478
to
0a2b364
Compare
0748244
to
628c9e0
Compare
628c9e0
to
234a6ad
Compare
bda9ebe
to
0729b55
Compare
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 am to be honest still not convinced that this API doesn't have so many special cases compared to other locators it wouldn't make more sense to just have browsingContext.getContainer
, but I guess if this is the direction more people are happy with then I think the implementation is basically correct.
Thanks, started working on some WPT tests web-platform-tests/wpt#50023 |
This change adds a new locator called
context
: when called for a parent navigable, given a child navigable as a locator, it locates the container element for the child navigable that is located within the parent navigable. While providing the parent navigable is redundant and it can be computed based on the child navigable, the interface matches existing locators which all select a node within the parent navigable that matches the locator criteria. In this case, the criterion is the child navigable identifier.Providing start nodes to this locator would currently trigger an invalid argument error but eventually it could be supported if there is a use case.
Closes #794
Preview | Diff