W3C home > Mailing lists > Public > public-browserext@w3.org > December 2019

Re: ES Modules in Content Scripts

From: Rob Wu <rob@robwu.nl>
Date: Tue, 17 Dec 2019 15:25:08 +0100
Message-ID: <CAA+18=yXLiR2CS50z5T0awx3JbffDCBDW_38nbEDKSctMr1kaA@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: Adaline Simonian <adalinesimonian@gmail.com>, public-browserext@w3.org, Simeon Vincent <simeonv@chromium.org>
Hi Adaline,

Firefox is not actively working on supporting ES6 modules in content
scripts, but has the following open issues to track this feature:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1451545
- https://bugzilla.mozilla.org/show_bug.cgi?id=1536094 (about dynamic
imports)

Chromium does not have an issue on their issue tracker or in their
chromium-extensions
mailing list
<https://groups.google.com/a/chromium.org/forum/#!forum/chromium-extensions>,
so I am adding Simeon (extension developer advocate at Google) to the
conversation to see where they are at. Simeon, is (dynamic) module support
in content scripts part of your roadmap?

Kind regards,
 Rob
 https://robwu.nl


Op di 17 dec. 2019 om 04:41 schreef Florian Rivoal <florian@rivoal.net>:

> Hello Adaline,
>
> The needs you express in your mail seem very legitimate to me, and this
> certainly sounds like something that should at least be explored.
>
> However, as you have noticed, this group has become inactive. I still
> think that browser extensions ought to be standardized fully, but
> unfortunately at the best of times this group barely reached critical mass
> to function, and eventually couldn't hold up. I don't think anybody is
> opposed to the work happening, but not enough people could commit the time
> to make it work.
>
> If this email of yours here doesn't catch the attention of browser vendors
> (and give how quiet it's been, I suspect it might not), I'd suggest you try
> do some out-reach in various venues on this topic. You can try social media
> in general to recruit more people to your cause in order to prove that this
> is a pressing need, you can try the various browsers bug trackers to
> request the feature, and you can have a go at https://discourse.wicg.io/
> which is a place within w3c used to propose ideas "to the crowd" and see
> what sort of feedback you get.
>
> I realize this is likely to be a lot of work, and had this community been
> active, reaching out here would have been the right thing to do, and likely
> simpler. But it's not, so here we are.
>
> Wishing you the best of luck
> —Florian
>
> On Dec 15, 2019, at 12:22, Adaline Simonian <adalinesimonian@gmail.com>
> wrote:
>
> Hello,
>
> I see this group has largely gone silent in its online presence so I hope
> this email doesn't fall through the cracks. I hope y'all are still around
> and doing well!
>
> ES modules have been available in both Chrome and Firefox for some time
> now - Chrome has supported dynamic imports since version 63 and Firefox
> since 67, and the upcoming Chrome release (80) also brings module support
> to workers.
>
> Content scripts, however, have been largely neglected. Unlike background
> pages, browser actions, page actions, and options pages, where you can just
> set type="module" on a script tag, content scripts remain the sole part of
> the extension format where you cannot use ES modules at all. You can *kind
> of* work around the issue by injecting a type="module" script tag into
> the target page and using web-accessible resources, but you lose access to
> all the layers of separation and the APIs available to content scripts..
> You can't reclaim the separation given to content scripts, and you can only
> regain the API access by means of a huge amount of implementation overhead
> to use messaging between the injected scripts and background scripts to
> play a game of telephone with the APIs.
>
> From a spec point of view, it doesn't seem to be such a hard problem to
> crack on the surface in a backwards-compatible fashion: consider, for
> example, an additional property in the manifest under "content_scripts"
> such as "js_modules", which would function just as "js" functions now but
> with the distinction that any entry in the "js_modules" array is added to
> the respective context as a module, hence allowing the use of `import` and
> `exports` without resorting to 3rd party tooling that can bloat what may
> otherwise be a relatively clean and dependency-limited extension.
>
> With the current state of support that Firefox and Chrome, the two largest
> supporters of the browser extensions standard, have for current ES syntax
> and functionality, it only seems natural to allow content scripts to be
> organised as modules. Currently I'm authoring an extension for Firefox
> where I've been able to completely write dependency-free code using modern
> syntax. The only place where I'm hitting a hard limit is content scripts.
>
> Of course, updating the spec is no substitute for implementation work, but
> implementation work can't happen without corresponding work on the spec.
>
> Hope to hear from you!
>
> Kind regards,
> Adaline Simonian
> she/her
>
>
>
Received on Tuesday, 17 December 2019 14:25:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:03 UTC