Expose openOrClosedShadowRoot for userscripts

[tophf]

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.