Open Bug 1451545 Opened 7 years ago Updated 1 year ago

Support loading content scripts as ES6 modules

Categories

(WebExtensions :: General, enhancement, P3)

57 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: e7358d9c, Unassigned)

References

Details

(Whiteboard: [dev-ux])

Spun off from bug 1394303, because allowing content scripts to be modules is much more complex than doing the same thing for background scripts. (In reply to ExE Boss from bug 1394303 comment #9) > If we add a `module` property to the `background` manifest key, we should > also add it to the `content_scripts` key, as that also needs to support > being a module, and unlike background scripts, where there’s the workaround > of using a background page, there’s no currently way to load content scripts > as modules. (In reply to Kris Maglione [:kmag] from bug 1394303 comment #10) > This is a trivial change for background scripts. For content scripts, it > would be a very large amount of work.
Priority: -- → P3
Can we consider doing this? manifest support: ``` "content_scripts": [ { "matches": ["*://*.mozilla.org/*"], "js": [{ "type": "module", "src": "borderify.js" }] } ] ``` Browser Extension API support: ``` browser.tabs.executeScript({ type: 'module', code: `console.log('location:', window.location.href);` }); ```
We can consider doing something like that, though I'd prefer "module": "borderify.js" to match the <script> tag behavior. But considering doing it and actually doing it are separate things. Supporting this requires a large amount of platform work.
No longer blocks: harmony:modules
No longer depends on: modules-0
No longer blocks: shumway-webext
Product: Toolkit → WebExtensions
Severity: normal → enhancement
Whiteboard: [dev-ux]
See Also: → 1536094
See Also: → 1775574
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.