Proposal: declaring background scripts in a neutral way #282
Description
Edit by @Rob--W on 2023-02-24: The spirit of this feature request is to enable cross-browser development with a single manifest file. Chrome opposed the initial proposal that is described below, but after proposing an alternative solution that consists of allowing
service_workerandscriptsto co-exist (with the latter being ignored in Chrome), the position changed to Chrome being supportive.
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:
"background": {
"scripts": ["script1.js", "script2.js"]
}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():
importScripts(
'script1.js',
'script2.js'
);Browsers only supporting limited event pages would generate a _generated_background_page.html which imports the scripts using script tags:
<head></head><body>
<script src="script1.js"></script>
<script src="script2.js"></script>
</body>Browsers supporting both serviceWorkers and limited event pages would choose based on their own preference. We can let developers set preferred_environment to serviceWorker or page which browser vendors can ignore as such:
"background": {
"scripts": ["script1.js", "script2.js"],
"preferred_environment": "serviceWorker"
}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:
import "./script1.js";
import "./script2.js";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:
<head></head><body>
<script type="module" src="script1.js"></script>
<script type="module" src="script2.js"></script>
</body>See #289