-
Notifications
You must be signed in to change notification settings - Fork 66
Proposal: declaring background scripts in a neutral way #282
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.
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
Comments
One thing that makes this potentially less impactful is that lots of developers use bundlers which handle this sort of thing automatically. That said - adding an extra script is currently the path recommended in https://github.com/mozilla/webextension-polyfill and I think that speaks to the benefits of keeping code snippets that work in MV2 working in MV3. |
@oliverdunk bundlers can be very useful indeed and also using them in many of my extension projects. The point of this request was also to align declaring background scripts across browsers independent on whether or not the browsers use serviceWorkers or event pages. Adding the webExtension polyfill is one of the use cases. Another one is reusing script files across your options pages, popup pages, content scripts and background pages. As you mentioned I also very much support the idea of reducing friction when switching manifest versions. |
I do believe there should be at least a way to declare both Event Pages and Service Workers in a single manifest (the script performs browser check in case a browser implements both). This helps people downloading builds from GitHub zipball, those developing extensions on tablets or Chromebooks (yes, they do exist), or those who can't use bundlers for some reason. |
How would automatic import work for |
@tophf That is a good catch. Since the ServiceWorker with type moduleSo in the case of import "./script1.js";
import "./script2.js"; limited event pages with type moduleIn the case of limited event pages, we can actually also start supporting |
Any update on this? I understand this is a lot more complicated, but being able to use one |
Safari and WebKit now support |
@xeenon, just to make sure I understand, with this change is the following manifest.json valid in Safari? {
"name": "Demo",
"version": "0.0.1",
"manifest_version": 3,
"background": {
"scripts": ["lib.js", "background.js"],
"type": "module"
}
} |
I recently had a chance to discuss the original proposal with other Chrome folks. At the moment we have significant reservations with using a minimal set of manifest fields that work across all browsers. We expect that this approach will lead to situations where background scripts authored for page contexts or service worker contexts will be executed in a different environment from what the author expected and, as a direct result, unexpected runtime behavior. As such, we are currently opposed to the proposed introduction of a That said, we did not discuss (and I think it may be worth exploring) other approaches to defining a single manifest file that works across multiple environments. For example, rather than have a way for a developer to suggest an execution environment, perhaps we could have an explicit declaration of entry points per environment. |
Any updates? Chrome should suggest an alternative proposal that they wouldn't oppose. We at the Scratch Addons open-source extension (100,000+ users) are watching this closely. Is it reasonable that updating to MV3 will force us to use a bundler? We have been considering adding a bundler to our workflow for some time, but did not foresee that we would need to hurry because of Manifest V3. |
Updated labels to reflect that Firefox and Chrome now support declaring event pages and a
|
Was a priority order established? What would be loaded (now and/or in future when all are supported) by Firefox, Chrome & Safari with the following entry? "background": {
"scripts": ["background.js"],
"service_worker": "background.js"
} preferred_environmentThe important aim of dealing with inconsistencies in the For Chrome "background": {
"preferred_environment": [ "service_worker" ],
"service_worker": "background.js",
"scripts": [ "background.js" ]
}
For Firefox "background": {
"preferred_environment": [ "document" ],
"page": "background.html",
"scripts": [ "background.js" ]
} If using a "background": {
"preferred_environment": {
"firefox": "scripts",
"chrome": "service_worker",
"safari": "scripts"
},
"service_worker": "background.js",
"scripts": [ "background.js" ]
}
|
@erosman with: "background": {
"scripts": ["background.js"],
"service_worker": "background.js"
} As rob mentioned before: Per #282 (comment), Safari prefers scripts, page, then service_worker when they are all specified; Previously service_worker came first. When Firefox ships service_worker support, it will also prefer Event pages over service workers (#282 (comment)). Chrome will simply ignore the @erosman Why would Use If however you want to prefer |
@carlosjeurissen I see... therefore, in future when both service In the following example: "background": {
"preferred_environment": [ "scripts" ],
"service_worker": "worker.js",
"scripts": [ "background.js" ]
}
What would be the outcome of the following? "background": {
"service_worker": "worker.js",
"scripts": [ "background.js" ]
}
For the sake of being thorough, I would imagine "background": {
"preferred_environment": [ "scripts" ],
"service_worker": "worker.js"
} |
@erosman The outcome of the following would be: "background": {
"service_worker": "worker.js",
"scripts": [ "background.js" ]
} Chrome loads: service_worker As for: "background": {
"preferred_environment": [ "scripts" ],
"service_worker": "worker.js"
} For the extension developer, having the browser give a warning or even an error when an extension is loaded with this manifest would be preferred as This is actually why I suggested to use |
Indeed, @carlosjeurissen |
Closing this issue as it has been implemented in all browsers. |
Reopening. I didn't realize that implementation of |
In addition to the |
Note: Safari 18 defaults to an event page ("scripts" or "page") over a service worker ("service_worker") instead of the opposite, if both are specified (see commit: https://commits.webkit.org/275916@main). The Safari 18 also introduces support for auto-generating the worker from the The cross-browser documentation for this behavior is at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/background#browser_support . Safari's changes are not included yet, that will be done as part of mdn/content#35630 |
To clarify, is the following the agreed behaviour when BOTH Chrome
Firefox & Safari
|
Yes, but only when Firefox enables support for service_worker, which it has not yet. Firefox only supports document-based background pages for now. |
Bearing in mind the objective of cross-browser
Chrome
Firefox & Safari
Therefore, the following appears to cover the objective adequately.
P.S. Chrome outputs an error in Developer mode |
@erosman background.preferred_environment should be an array. This has been designed like this on purpose. See: In addition, |
@carlosjeurissen Thank you. I will update my post. However, the point remains unchanged. |
@erosman Without Chrome support, this property offers limited benefits. Currently, its primary purpose is to future-proof our API surface, ensuring compatibility with potential future choices. Safari and Firefox plan to support multiple environments, and this property facilitates that by allowing extensions to specify only |
@erosman in addition, Firefox original plan was to default to In addition, once Mozilla would actually start supporting |
Edit: As this issue has mostly been defined by allowing @dotproto Can we rename |
Since the group currently does not agree what the future of background scripting should look like Safari and Firefox with limited event pages, Chrome with serviceWorkers
To make sure developers can define their background scripts in both situations I am proposing the following syntax:
Browsers only supporting serviceWorkers would use the script directly as serviceWorker if only one script is defined. If multiple script files are listed, it will create a generated serviceWorker named
_generated_service_worker.js
just like browsers currently generate a_generated_background_page.html
. This serviceWorker will import all scripts using importScripts():Browsers only supporting limited event pages would generate a
_generated_background_page.html
which imports the scripts using script tags:Browsers supporting both serviceWorkers and limited event pages would choose based on their own preference. We can let developers set
preferred_environment
toserviceWorker
orpage
which browser vendors can ignore as such:Why is this important? This will lead to a more optimal contract between the developer and the browser. In which the developer is able to communicate their preferred environment while allowing browsers to decide what environment extensions should be using. This also makes sure browsers can change their preferred environment over time and have their own approach towards background script handling.
This also has the added benefit of allowing browsers to support both mv2 and mv3 like Safari does right now.
"type": "module"
This syntax works perfectly fine with type module as well by using imports in the serviceWorker, or the type module attribute for the limited event page.
In the case of
"type": "module"
, the_generated_service_worker.js
would look like this:In the case of limited event pages, we can actually also start supporting
"type": "module"
by adding it to the_generated_background_page.html
as such:See #289
The text was updated successfully, but these errors were encountered: