Closed Bug 1811443 Opened 1 year ago Closed 1 year ago

Support type: "module" (event page, not background service worker)

Categories

(WebExtensions :: General, enhancement, P1)

enhancement

Tracking

(firefox112 fixed)

RESOLVED FIXED
112 Branch
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).

Severity: -- → N/A
Priority: -- → P1
Whiteboard: [wecg] → [addons-jira][wecg]
Assignee: nobody → lgreco
Status: NEW → ASSIGNED
Pushed by luca.greco@alcacoop.it:
https://hg.mozilla.org/integration/autoland/rev/cd11b62d9961
Support optional background.type "module" for WebExtensions Event Page scripts. r=willdurand,robwu
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch

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';

(In reply to erosman from comment #4)

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?

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.

(In reply to erosman from comment #4)

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?

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).

Thank you Luca & Rob for the explanation.

MDN content: #25094
BCD: #19055

Duplicate of this bug: 1394303
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: