Support type: "module" (event page, not background service worker)
Categories
(WebExtensions :: General, enhancement, P1)
Tracking
(firefox112 fixed)
| Tracking | Status | |
|---|---|---|
| firefox112 | --- | fixed |
People
(Reporter: robwu, Assigned: rpl)
References
Details
(Keywords: dev-doc-complete, Whiteboard: [addons-jira][wecg])
Attachments
(1 file)
I'm splitting this off bug 1775574: That bug is about introducing support for type: "module" for service worker-based extensions, but that has dependencies that do not necessarily apply to event pages.
In this bug we can focus on adding type: "module" to event pages, which is trivial to do.
Even if we land this change now, extensions may still choose to use background.page + <script type="module" src="..."></script>, because adding a type property would prevent the extension from loading in Firefox versions that don't recognize the property (like bug 1775618).
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
Reporter | |
Updated•2 years ago
|
|
Assignee | |
Comment 1•2 years ago
|
||
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 3•2 years ago
|
||
| bugherder | ||
For clarification purposes, how is import sequenced in an array of background.scripts and how would the accessibility of modules be, when more than one JS script is injected into the same background context?
manifest.json
"background": {
"scripts": ["bg1.js", "bg2.js"],
"type": "module"
},
bg1.js
import {mod1} from './mod1.js';
import {mod2} from './mod2.js';
bg2.js
import {mod3} from './mod3.js';
import {mod4} from './mod4.js';
|
|
Assignee | |
Comment 5•2 years ago
|
||
(In reply to erosman from comment #4)
For clarification purposes, how is
importsequenced in an array ofbackground.scriptsand how would the accessibility of modules be, when more than one JS script is injected into the samebackgroundcontext?
The background scripts are not injected, they are loaded as tag scripts included in the auto generated background page (the one named _generated_background_page.html which is used when the extension didn't provide its own using the background.page manifest field).
The behavior to expect is exactly same to expect for an extension that explicitly defines the HTML of the background page and loaded each of the module as scripts tags with type set to "module" in the same order they are listed in the background.scripts array:
<!DOCTYPE html>
<html><head><meta charset="utf-8"></head>
<body>
<script type="module" src="moz-extension://.../bg1.js"></script>
<script type="module" src="moz-extension://.../bg2.js"></script>
</body></html>
and so setting background.type to "module" is basically a shortcut, and it allows to achieve the same outcome without having to switch from background.scripts to background.page and define the background page HTML manually just because you'd like to load the scripts as ES modules.
|
|
Reporter | |
Comment 6•2 years ago
|
||
(In reply to erosman from comment #4)
For clarification purposes, how is
importsequenced in an array ofbackground.scriptsand how would the accessibility of modules be, when more than one JS script is injected into the samebackgroundcontext?
Each specified script is loaded via <script type="module"> in the given order. The usual behavior of modules applies. So in your example, both scripts have their own (module) scope with the mod1/mod2 and mod3/mod4 being only available to the modules themselves. They also share a global scope (globalThis) where the usual (extension and DOM) APIs are found.
Another feature of module scripts is that modules are loaded only once, so if you specify a script twice in the scripts array, it will be executed once when loaded as a module (and twice when loaded as a classic script).
Description
•