Open versusvoid opened 2 years ago
I support disabling customElements
in content scripts. (Chrome behavior now).
I think this is the relevant Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=390807
This disabling is only for isolated worlds, correct?
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).
@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!
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?