Skip to content
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.

Sign up for GitHub

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

Jump to bottom

create specification for self.browser #508

Merged
merged 14 commits into from
Jan 29, 2024
Merged

create specification for self.browser #508

Show file tree
Hide file tree
Changes from 9 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
74784f2
create specification for window.browser
patrickkettner Dec 14, 2023
ffcf572
feedback from PR for window.browser
patrickkettner Dec 20, 2023
9abc5e6
Update specification/window.browser.bs
patrickkettner Dec 21, 2023
77cbbf0
Update specification/window.browser.bs
patrickkettner Dec 21, 2023
0c97892
update metadata in spec
patrickkettner Dec 26, 2023
35f8f21
add browser to worker scopes
patrickkettner Dec 26, 2023
2a84e05
Update specification/window.browser.bs
patrickkettner Jan 4, 2024
3679214
Update specification/window.browser.bs
patrickkettner Jan 4, 2024
a41e4cd
Update specification/window.browser.bs
patrickkettner Jan 4, 2024
9ca1dd0
Update specification/window.browser.bs
patrickkettner Jan 26, 2024
87d00fe
Update specification/window.browser.bs
patrickkettner Jan 26, 2024
e442b0f
Update specification/window.browser.bs
patrickkettner Jan 26, 2024
3952d20
removed unused code
patrickkettner Jan 26, 2024
2dd59f1
update version
patrickkettner Jan 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions specification/window.browser.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
<pre class="metadata">
Title: window.browser
Shortname: wecg-browser
Level: 1
Group: wecg
Status: UD
URL: https://w3c.github.io/webextensions/specification/window.browser.html
Editor: Patrick Kettner, Google, [email protected]
Abstract: This specification reserves the <code>window.browser</code> namespace for use by WebExtensions.
Repository: w3c/webextensions
Complain About: accidental-2119 on, missing-example-ids on
</pre>

<pre class=link-defaults>
spec:html; type:attribute; text:window
</pre>

<pre class="anchors">
spec: html; urlPrefix: https://html.spec.whatwg.org/multipage/
type: dfn; text: valid non-empty URL; url: valid-non-empty-url-potentially-surrounded-by-spaces
</pre>

<section class="non-normative">
## Introduction {#introduction}
patrickkettner marked this conversation as resolved.
Show resolved Hide resolved
<em>This section is non-normative.</em>

Browser extensions are programs to extend the capabilities of web browsers.
Although not standardized at first, web browsers have independently implemented a common interoperable set of extension APIs, called WebExtensions.

Modern WebExtensions are an evolution of a system originally introduced in
patrickkettner marked this conversation as resolved.
Show resolved Hide resolved
Chrome version 3. In that system, any API that was added was put under the
patrickkettner marked this conversation as resolved.
Show resolved Hide resolved
<code>chrome</code> namespace. When WebExtensions were adopted outside of
Chromium, other vendors used the more neutral <code>browser</code> namespace.
That <code>browser</code> is now considered the canonically correct namespace
for all WebExtension APIs. Some interactions with WebExtensions (such as
external messaging from websites to background processes) necessitate
the exposure of this namespace to the web.

Given that, this document defines <code>window.browser</code> as reserved for
the use of APIs designed to interact with WebExtensions. The specifics of what
APIs within <code>window.browser</code> are at present intentionally undefined,
and are left up to User Agent implementation.
</section>


<section>
<h3 id="window-interface">
<a attribute lt="browser"><code>window.browser</code></a> API
</h3>

{{browser}} is UA defined attribute exposed on {{window}}. When implemented,
it MUST be used only for WebExtension related functionality.
</section>


<pre class="idl">
partial interface Window {
attribute object browser;
oliverdunk marked this conversation as resolved.
Show resolved Hide resolved
};

</pre>

<section>
<h3 id="worker-interface">
Worker API
</h3>

When {{browser}} is defined on {{window}}, it SHOULD also be implemented on {{ServiceWorkerGlobalScope}} and {{DedicatedWorkerGlobalScope}}.
patrickkettner marked this conversation as resolved.
Show resolved Hide resolved
It MUST be used exclusively for WebExtension purposes, however the contents of each instance of {{browser}} is UA defined.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: The mention of Service Workers here may raise questions, because Service workers are defined for http(s) URLs only: https://w3c.github.io/ServiceWorker/#start-register-algorithm
(in practice mainly https, http is only supported for edge cases such as localhost).

Chrome (and Firefox's experimental implementation) does not permit extension code to register arbitrary service workers. Instead, the extension framework takes care of registering workers despite the http(s) restrictions.

Should we clarify in a note that extensions cannot register Service workers as usual (i.e. the https restriction), but that browsers may spawn a Service worker associated with a WebExtension origin?

Should we drop the mention of workers entirely from this "window.browser" document, and define the worker behavior in an entirely separate spec/PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback @Rob--W!

because Service workers are defined for http(s) URLs only: https://w3c.github.io/ServiceWorker/#start-register-algorithm (in practice mainly https, http is only supported for edge cases such as localhost).

I am not sure I follow. The spec in this PR says that if window.browser is defined, then self.browser should be defined on any ServiceWorkerGlobalScope whose origin is a webextension. While the service worker spec is only http(s), the thing that is registered as a background script in Chrome for manifest v3 is
ServiceWorkerGlobalScope.

Chrome (and Firefox's experimental implementation) does not permit extension code to register arbitrary service workers. Instead, the extension framework takes care of registering workers despite the http(s) restrictions.

If they are not permitted, then I don't see the problem? ServiceWorkerGlobalScope is what is created when you have an extension in Chrome/Firefox's-experimental-implementation. Can you explain what you are wanting changed?

Should we clarify in a note that extensions cannot register Service workers as usual (i.e. the https restriction)

While I see the use for that in a broader web extensions specification, as there is no other portion of this document is about registering a service worker, or when it should be registered on window. That seems outside of this document's scope.

Should we drop the mention of workers entirely from this "window.browser" document, and define the worker behavior in an entirely separate spec/PR?

Given the current level of web extension specification, having two essentially identical documents to accomplish the same thing ("globalThis.browser should only be used for web extensions") feels unnecessary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback @Rob--W!

because Service workers are defined for http(s) URLs only: https://w3c.github.io/ServiceWorker/#start-register-algorithm (in practice mainly https, http is only supported for edge cases such as localhost).

I am not sure I follow. The spec in this PR says that if window.browser is defined, then self.browser should be defined on any ServiceWorkerGlobalScope whose origin is a webextension. While the service worker spec is only http(s), the thing that is registered as a background script in Chrome for manifest v3 is
ServiceWorkerGlobalScope.

In the realm of specifications, Service Workers (and thus ServiceWorkerGlobalScope instances) only exist on https schemes (and localhost). Here we specify that ServiceWorkerGlobalScope should have a browser object, for WebExtension origins only. I initially found this inconsistent, because the SW spec doesn't leave room for SW on other schemes, while our spec here implies the existence of an extension origin.

I have now reconciled this inconsistency by observing that "extension origin" could theoretically also involve one of the accepted schemes (even though that doesn't happen in practice - as an example from a far past, Chrome had the concept of Hosted apps where regular websites received extra privileges if a crx file defining the "hosted app" was installed).
We (browser vendors) understand the intent and practical meaning here, and I am fine with not mentioning anything more about SW for now.

</section>

<pre class="idl">
partial interface DedicatedWorkerGlobalScope {
attribute object browser;
};

patrickkettner marked this conversation as resolved.
Show resolved Hide resolved
partial interface ServiceWorkerGlobalScope {
attribute object browser;
};
</pre>
Loading