-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
feat(text selector): pierce shadow roots #1619
Conversation
- Text body can also be a JavaScript-like regex wrapped in `/` symbols. This means `text=/^\\s*Login$/i` will match `<button> loGIN</button>` with any number of spaces before "Login" and no spaces after. | ||
|
||
> **NOTE** Text engine searches for elements inside open shadow roots, but not inside closed shadow roots or iframes. |
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.
Will we consider it a breaking change if this starts piercing closed shadow dom?
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.
Most likely.
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.
Minor detail: Isn't this text better left as a generic paragraph/section/note about shadow DOM, and then saying "This is only currently supported by the text engine". Reason is that you can then easily amend with "text engine, css engine" etc.
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.
Thanks for pointing this out. I don't think css will ever support shadow dom - that would be against the css spec. We'll probably make attribute selectors pierce shadow dom as well, and I'll make this note more generic.
src/injected/textSelectorEngine.ts
Outdated
|
||
function queryInternal(root: SelectorRoot, matcher: Matcher): Element | undefined { | ||
const document = root instanceof Document ? root : root.ownerDocument; | ||
if (!document) |
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.
if (!document) | |
assert(document); |
This is an assert right? ownerDocument should be never null unless root is a document.
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.
That's right! We don't have asserts in the injected code though, so I am not sure how to change this.
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.
just ownerDocument!
then? The if there makes me try to reason about the null case and I go down a bad path.
I did not address any comments, please take another look :) |
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 think any time you get the opportunity to correctly use a generator you should, because then you can win arguments against people who say it is useless 😄 .
References #1375.