search

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
578 stars 50 forks source link

create specification for self.browser #508

Closed patrickkettner closed 5 months ago

patrickkettner commented 6 months ago

Create specification for window.browser/self.browser.

preview available here

patrickkettner commented 6 months ago

@Rob--W @xeenon would yall be able to review when time permits?

patrickkettner commented 6 months ago

thanks @xeenon! I added the bikeshed file. The current build system is using pr-preview, and configured to build the existing spec. pr-preview has a long running request to support multiple files, but the existing PR has been untouched for years. @dotproto and I discussed replacing the build system with something that supports multiple files built directly on bikeshed, rather than using pr-preview. I plan on digging into it soon. In the meantime, given devlin's desire to give a few months notice to developer before any change landing, I didn't want to block on that.

Jack-Works commented 6 months ago

are you considering renaming this PR (or part of the non-normative sections) to self.browser? that covers service workers.

patrickkettner commented 5 months ago

@Rob--W any thoughts?

Rob--W commented 5 months ago

I know that we wanted us to spec the existence of browser because Chrome considers a spec as a prerequisite to exposing this. The specific behavior of "browser" is left up to the UA, so my question here is not a blocking part of the review. Still, I'm curious about the ideas behind it.

Chrome (and Safari) both have the concept of "isolated world" for content scripts. An isolated world shares the same view of the DOM (DOM instances from native code are shared), with unique JavaScript wrappers (isolated per world). If window.browser were to be defined in the idl as part of window, what does that say about the value read by the main world vs isolated world? Is it the same (native) object, but with different wrappers that somehow filters the available extension API methods? Or is the browser namespace a different object (and therefore implicitly also a separate wrapper if any)?

Here is some background on isolated world and a description of bindings: https://chromium.googlesource.com/chromium/src.git/+/123.0.6266.0/third_party/blink/renderer/bindings/core/v8/V8BindingDesign.md

In Firefox, externally_connectable has not been implemented yet (bug 1319168), which means that there is no browser namespace in the main world, only in that of content scripts. The current implementation of the sandbox in Firefox is that globalThis is a sandbox inheriting from window. globalThis.browser is the extension API namespace, window.browser is currently undefined. I imagine that if we were to implement window.browser, that the main world version would be generated through WebIDL, and that the content script continues to have its own implementation-defined extension API namespace separate from window.browser.

xeenon commented 5 months ago

The Safari and WebKit implementations of web extensions currently dynamically add the browser object as needed to the DOM global object, per world. So it is always a different wrapper and a different internal object.

It needed to be different since the things contained in the browser namespace for the main world in web pages is drastically reduced and different from the extension content script world or main world in extensions pages.

We will likely continue to dynamically add this property to the global scope, instead of adding it in our DOM window IDL.

I don't think that fundamentally blocks anything here. Browser implementations can expose the APIs however their implementation requires, as long as it matches how the IDL in the spec defines it.