#771 Packaging guidelines for webextensions
Opened 5 years ago by tibbs. Modified 5 years ago

So, we could use some packaging guidelines for webextensions, since Firefox switched and we now have Chromuim and some "official" endorsement of Chrome itself. Plus we just touched on this issue with the /opt/etc/chrome thing, so we might as well finish it.

I will work on an initial draft, since it should be pretty simple. However, there are some open questions I'll need to figure out.

  • Do we care if these are "built from source"? An xpi file is just a zip archive with javascript, local content and metatata. (I'm assuming that there are no webassembly extensions right now, but that's probably naive.)
  • I have no idea about how to handle signatures. Obviously if we insist on things being built "from source" then we can't include signed extensions, but that may not matter for firefox. No idea about chrome/chromium.
  • At least some chrome extensions take the form of a pointer to the store and nothing else. Is this problematic?

More to come as I work through this.


So, yeah, it turns out that for chrome (and probably chromium without patching) the best you can do is give it a pointer to a google server unless things are specifically set to developer mode. The browser will then pull the extension into the per-user configuration for each user when they start the browser.

At this point I have no idea if it will then auto-update the extension or if it is bound to a specific version.

Still, as distasteful as this is, FESCo and particularly the council appear to have embraced chrome and so we will see packaged extensions (and already have two or three of them) and should still provide some guidance. Fortunately firefox isn't broken in this way.

Login to comment on this ticket.

Metadata