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
[Feature] Native shadow DOM support #1375
Comments
@dgozman Could you explain a bit how the native implementation you are working on is supposed to be used in certain cases. As an example, a heavy Web Component page will have nested upon nested CSS in the Shadow DOM. If I use Playwright, I do not really care about this, I just want to scrape or write an e2e test and know that I have a deeply nested element called page.type('my-awesome-element #foo') // Using css engine by default This is nice and not too verbose. I'd prefer to not have to write this: page.type('css=my-awesome-element >> css=#foo') Or does that even work if |
I totally agree. However, we cannot change
This would not work. Your usecase is "any space separator is treated as In fact, I am inclined to remove support for
|
It's not necessarily that In a Web Component riddled site, can you explain how I would use Playwright? Let's say I have an How do I use Playwright to click the up arrow? |
We definitely want to address this usecase, as it is a part of web standards. Our current approach with cc @Georgegriff |
Awesome! I'll follow this with keen interest :) |
Executing a walk of nodes in shadow from the browser context will be limited to I suggest using the pierce option (from If this is done, you'll need to allow custom selectors to work against arbitrary trees (supplied by an async fn) instead of always running in the page context. This will allow me to create a custom engine plugin for the axTree as well since it needs to operate on the CDP session object and not the DOM. Instead of NOTE: this would also allow selectors to traverse iframes. |
I noticed #152 was merged with this issue. There was a comment indicating support for entering iframes and using any selector inside the iframe. Does this issue also encompass that as well or should I open a separate issue? The reason I ask is because iframe support is the most requested feature we have. It would be great if we could enter an iframe and use our custom selector engine inside it:
|
We decided to not enter iframes using const frame = await (await page.waitForSelector('#iframe-id')).contentFrame();
await frame.click('html=our-custom-selector'); Note that we are actively exploring the space, with a possibility of playwright-side selectors that can hide the frames complexity. For example (not implemented, just a possibility): await page.click(playwright.selector('frame=#iframe-id >> html=our-custom-selector'));
// or
await page.$frame('#iframe-id').click('html=our-custom-selector'); |
@AutoSponge We thought about this world of playwright-side selectors, and decided to not rush into it. The problem is that it introduces asynchrony in the selector process and a lot of additional overhead, so we have to be careful with it. We would also ensure cross-browser support before going this route. |
Thanks for the clarification 🙏.
|
@dgozman I noticed in #1784 that you now make css default pierce shadow dom? Previously it was said:
What has changed since that this stance was changed? I assume it is in effect not changed, as you have the new |
Exactly. We'll keep the strict spec-compliant behavior with |
I think shadow dom handling is in a good shape now, shipping in next release 🚀 |
Just took a little look at the code changes this look fantastic! |
Great work @dgozman and the Playwright team, and thank you so much to @Georgegriff for starting this kind of support with his awesome npm package. |
@dgozman I'm looking forward to this one. Another option for iframes is to pass // previous suggestion
await page.$frame('#iframe-id').click('html=our-custom-selector')
// alternate
await page.click(['#iframe-id', 'html=our-custom-selector'])
// or variadic
await page.click('#iframe-id', 'html=our-custom-selector') The down side is that would overload your interfaces that take a selector. |
@AutoSponge Thank you for the suggestion. I think variadic won't work for us, because we have options at the end, but something with an array might work. We'll keep looking. |
Web Components is a growing trend and statistics show it is used more often than major libraries like React. I've got no statistics on how often the shadow DOM is used though. In any instance, the shadow DOM is standardized, so I would assume people will expect support out-of-the-box.
The project https://github.com/Georgegriff/query-selector-shadow-dom works perfectly for now.
https://github.com/mmarkelov/jest-playwright#configuration also supports it nicely.
But seeing as it requires a new selectorEngine, means the nice selector engines like
css
,xpath
andtext
do not work on the shadow DOM by default.If Playwright would support adding a
penetrateShadowDOM
on a browser, browserContext or page, it would be amazing for usability.The text was updated successfully, but these errors were encountered: