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.

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.