Currently userscripts can't use elem.openOrClosedShadowRoot (Firefox) and chrome.dom.openOrClosedShadowRoot (Chrome) because it's exposed only in the isolated world.
There's a number of reasons it should be exposed to userscript worlds:
Userscripts need it to augment web pages e.g. to apply custom CSS to sites built on shadow DOM, example.
Userscripts are already privileged compared to the page scripts as they are installed by the user to act on the user's behalf.
If necessary, the owner extension is still able to control the availability of chrome.dom (Chrome) or Element.prototype.openOrClosedShadowRoot (Firefox) by overriding it before running the userscript.
Alternatively, chrome.userScripts.configureWorld may be extended with dom: true.
The internal implementation is trivial, so exposing it even by default is not costly and it won't set a bad example because DOM-related differences between worlds are intentionally avoided i.e. it's possible this will be the only such difference for a very long time.
In Chrome userscripts would benefit from other possible additions to chrome.dom namespace such as the ability to run a function in the main JS world of the page without creating a script element to avoid detection via MutationObserver and being able to get the [serializable] result of the function directly without the inherently unsafe usage of dispatchEvent in a potentially poisoned environment. FWIW, Firefox already has a different solution: wrappedJSObject+cloneInto+exportFunction.
There's no safe/easy workaround:
No secure cross-world communication yet.
Even with secure cross-world communication, it is wasteful to spin up an entire JS world just to access a trivial feature, especially since there's no way to unload it.
The cross-world communication is unlikely to support exchanging DOM elements directly as they're not compatible with the structured cloning algorithm, so the extension would need to exchange a random event id first, set up a listener, send MouseEvent with relatedTarget for the element. Really arcane stuff.
The only con I remember seeing in WECG is that the exposed API for userscripts should be as simple as possible and intentionally limited, but this feature isn't something complicated or privileged, it's rather a trivial DOM feature necessary for userscripts that frequently augment web pages. If anything should be removed, it's chrome.csi and chrome.loadTimes, which seem useless in a userscript.
Currently userscripts can't use
elem.openOrClosedShadowRoot(Firefox) andchrome.dom.openOrClosedShadowRoot(Chrome) because it's exposed only in the isolated world.There's a number of reasons it should be exposed to userscript worlds:
Userscripts need it to augment web pages e.g. to apply custom CSS to sites built on shadow DOM, example.
Userscripts are already privileged compared to the page scripts as they are installed by the user to act on the user's behalf.
If necessary, the owner extension is still able to control the availability of
chrome.dom(Chrome) orElement.prototype.openOrClosedShadowRoot(Firefox) by overriding it before running the userscript.Alternatively,
chrome.userScripts.configureWorldmay be extended withdom: true.The internal implementation is trivial, so exposing it even by default is not costly and it won't set a bad example because DOM-related differences between worlds are intentionally avoided i.e. it's possible this will be the only such difference for a very long time.
In Chrome userscripts would benefit from other possible additions to
chrome.domnamespace such as the ability to run a function in the main JS world of the page without creating a script element to avoid detection via MutationObserver and being able to get the [serializable] result of the function directly without the inherently unsafe usage of dispatchEvent in a potentially poisoned environment. FWIW, Firefox already has a different solution: wrappedJSObject+cloneInto+exportFunction.There's no safe/easy workaround:
The only con I remember seeing in WECG is that the exposed API for userscripts should be as simple as possible and intentionally limited, but this feature isn't something complicated or privileged, it's rather a trivial DOM feature necessary for userscripts that frequently augment web pages. If anything should be removed, it's
chrome.csiandchrome.loadTimes, which seem useless in a userscript.