Skip to content

Web Components behaviour in content scripts #210

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

Open
versusvoid opened this issue May 8, 2022 · 5 comments
Open

Web Components behaviour in content scripts #210

versusvoid opened this issue May 8, 2022 · 5 comments
Labels
inconsistency Inconsistent behavior across browsers

Comments

@versusvoid
Copy link

Been digging through Firefox's code trying to fix Web Components in extension content scripts (https://bugzilla.mozilla.org/show_bug.cgi?id=1492002).

I've found the core problem, it's specific for Firefox implementation, but now I'm not sure what "correct" solution should look like.

Right now Firefox's policy regarding normal JS objects looks like:

  1. content script sees page's objects only if explicitly asked (wrappedJSObject)
  2. page script sees extension's objects only if explicitly provided (exportFunction, cloneInto)

It seems reasonable to extend this policy to Web Components:

  1. content script sees page's component properties only if explicitly asked
  2. page script sees plain HTMLElement for content's components

but it may be just my narrow point of view.

Also right now window.customElements slightly breaks isolation between scripts (not sure if this is Firefox specific) since it is shared between contexts: if component was defined in page script, content script can't use the same name and vice versa.

Maybe "correct" solution would be disabling customElements in content scripts altogether?

@Jack-Works
Copy link

I support disabling customElements in content scripts. (Chrome behavior now).

@dotproto
Copy link
Member

I think this is the relevant Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=390807

@carlosjeurissen carlosjeurissen added the inconsistency Inconsistent behavior across browsers label May 31, 2022
@jonathanKingston
Copy link

This disabling is only for isolated worlds, correct?

@izogfif
Copy link

izogfif commented Dec 16, 2023

I support disabling customElements in content scripts. (Chrome behavior now).

As of 2023-12-16, in Google Chrome 119 on Windows creation of custom elements from inside content scripts is supported (at least with manifest V3). Accessing element.nodeType yields 1, while on Firefox (same extension, but in manifest V2) for the same element I get "permission denied" error when accessing nodeType property.

Update: never mind, apparently, @webcomponents/custom-elements polyfill is used in content script to make things work in Google Chrome. It's not required in Firefox (but yields lots of issues anyway).

@thusimon
Copy link

@webcomponents/custom-elements works on Chrome and Edge MV3 content script for quite some time, and still works fine on latest v120 (Dec 2023).
From an extension developer perspective, I would hope it also works for Firefox, so we can use reuse the code base to build extensions for Firefox. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inconsistency Inconsistent behavior across browsers
Projects
None yet
Development

No branches or pull requests

7 participants