Skip to content
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

Shadow DOM problems for extensions #647

Open
lapcat opened this issue Jun 27, 2024 · 6 comments
Open

Shadow DOM problems for extensions #647

lapcat opened this issue Jun 27, 2024 · 6 comments
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time supportive: safari Supportive from Safari

Comments

@lapcat
Copy link

lapcat commented Jun 27, 2024

Websites are increasingly using the shadow DOM for complex DOM hierarchies. Reddit is an example of a site that makes heavy use of the shadow DOM. I've also seen sites that are putting <video> elements inside the shadow DOM.

It's possible to override Element.attachShadow(), and this works ok, but the declarative shadow DOM is a nightmare for extensions. I understand that Chrome has chrome.dom.openOrClosedShadowRoot() and Firefox has Element.openOrClosedShadowRoot, but Safari has nothing, and in any case it's not performant to check every element in the document for potential shadow roots.

Here's a list of things my extension needs to do with shadow roots:

  1. Add event listeners
  2. Add styles
  3. querySelectorAll()
  4. MutationObserver.observe()

It would be great if there were some convenient and performant way for extensions to find shadow roots, for example if querySelectorAll() and MutationObserver.observe() outside the shadow DOM had an option to include shadow roots.

The shadow DOM is intended for encapsulating code within a site, but I don't think it's intended to make a site off-limits to extensions.

@github-actions github-actions bot added needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time labels Jun 27, 2024
@polywock
Copy link

polywock commented Jun 27, 2024

I understand that Chrome has chrome.dom.openOrClosedShadowRoot() and Firefox has Element.openOrClosedShadowRoot, but Safari has nothing,

On a related note, this browser inconsistency should be worked on. Maybe browser.dom should become a standard namespace.

@Rob--W
Copy link
Member

Rob--W commented Jul 2, 2024

While the request seems reasonable, I'm afraid that implementation complexion limits the feasibility of implementing your requested functionality, at least for querySelector and querySelectorAll.

The ability to look through the shadow DOM boundaries has come up many times before on the web platform, including use cases such as automation / testing. Search terms to use are "pierce" / "piercing" / "deep".

Examples:

"Support >>> combinator in static profile"
WICG/webcomponents#78

"Provide a shadow DOM-piercing querySelector and querySelectorAll for extensions" (https://bugzilla.mozilla.org/show_bug.cgi?id=1475869)

@lapcat
Copy link
Author

lapcat commented Jul 2, 2024

It would be sufficient, I think, if there was some kind of event that could be observed whenever an element gets a shadowRoot, regardless of whether that's via attachShadow or shadowrootmode. Upon observing such an event, the extension could take care of everything else itself.

A piercing querySelector would be nice but not necessary.

@dotproto
Copy link
Member

dotproto commented Jul 4, 2024

Thinking out loud for a moment, perhaps we should make a point of collecting CSS issues related to WebExtensions so that we can bring them to the CSSWG. Perhaps if we have some specific use cases that we think should be supported in extensions if not the broader web, they would be open to working with us to integrate user agent-only allowances into the relevant specs.

@Rob--W
Copy link
Member

Rob--W commented Jul 4, 2024

Note #624 covers the event listener use case of this request.

@xeenon xeenon added supportive: safari Supportive from Safari and removed needs-triage: safari Safari needs to assess this issue for the first time labels Sep 24, 2024
@Rob--W
Copy link
Member

Rob--W commented Dec 5, 2024

FYI case 3 of this request is covered by the discussion in the WHATWG:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time supportive: safari Supportive from Safari
Projects
None yet
Development

No branches or pull requests

5 participants