Half a year ago, I decided I wanted to write an ebook-reader extension for Firefox.

I was, I thought, following in the grand tradition of such extensions as EPUBReader, whose interface I have a number of issues with but whose basic concept I’ve always found very solid. The EPUB format is sufficiently based on web technology that the web browser is the natural home for it, after all. And a browser extension is more conveniently accessible than either a loose bundle of HTML files (which less technically-inclined users are likely to struggle to make use of) or a website (which requires internet access to get access to, rather than being storable via a convenient offline file).

This was, in retrospect, a mistake.

In an ideal world, certainly, I would have been correct. In that ideal world, Firefox extensions would be able to serve up local pages which would behave identically to those served up by a webserver, involving neither extra features nor extra sandboxing. But that is not the world we live in. In fact, Firefox extension pages are, on a number of levels, sandboxed more aggressively than those of externally-sourced websites.

Sandbox 1: extensions are sandboxed out from each other’s pages.

Browser extensions are usable, not just to serve pages up to the user, but to inject new behavior into preexisting pages. A user might well have many of them running in the background of every webpage they open, providing functionality such as userstyles, quick dictionary lookups, or the like.

However, extensions aren’t allowed to run background scripts on one another’s pages. Which is to say: if you’re running Stylus as a source of userstyles, and you’re running the EPUBReader extension, Stylus isn’t allowed to apply a userstyle to the EPUBReader extension page. And the same holds for any other extension page you might want to open.

Thus extension pages, as compared with ordinary webpages, are much less able to enjoy the full benefits of being viewed from a web browser. They’re stuck with only the browser’s native functionality plus whatever features they implement themselves, rather than, as with other webpages, being fully extensible with features implemented by anyone.

Sandbox 2: extension pages can’t install service workers.

Service workers are a very cool piece of browser tech which make it possible for a site, once visited, to intercept requests from users to that site, parse them, and return arbitrary responses thereto. Their chief intended functionality is as a caching mechanism, to allow a site to preserve part or all of its functionality even when the user is offline; however, they’re ultimately very versatile tools with a wide variety of potential uses.

They’re also completely unusable from extension pages.

This, unlike the prior point, is acknowledged by Firefox’s developers as a flaw to be worked on, rather than being a deliberate design decision—there’s an open Bugzilla issue on the matter, thanks to the heroic efforts of the Kiwix extension developers—but the issue is moving slowly, with no particular urgency. So, while the fact of its being worked on may be a comfort to future developers a few years out, at the moment it’s another area in which Firefox extension pages are weakened relative to ordinary webpages.

Alternatives

The last two sections are, probably, an incomplete list. Those are the two major sandboxing-related issues I, personally, have run into in the course of my extension-development efforts thus far; but I’ve explored only part of the realm of web functionality that a page might want to make use of, and I imagine there are further restrictions I’ve missed which will be equally inconvenient for those to whom they’re relevant. But even those, alone, are sufficient to make clear that Firefox extension pages are substantially weaker than ordinary webpages in some important ways.

Unfortunately, this isn’t the sort of post I can end off with “and here’s the better alternative which captures all desirable attributes extension pages lack”. Because, to the best of my current ability to discern, no such alternative exists. Nonetheless, there are various alternatives which are better in certain ways, even if not in all ways. So I’ll end this post off with an enumeration of each of them, and their strengths and weaknesses relative to extension pages.

1. An ordinary webpage, or progressive web app, accessed via HTTPS. This is the simple and easy solution. However, it requires the user to have internet access, at minimum, the first time they use the page; unlike browser extensions, the user can’t save an offline installer for later use. Thus any users concerned with the longevity of their access to your page’s functionality will be justifiedly cautious about this option, and potentially prefer other alternatives as such.
2. An ordinary webpage, served up by a webserver launched by a local executable. An increasingly common and popular answer. But this has costs both in compatibility (limiting the page’s functionality to only those systems for which you can generate a compatible executable, rather than all systems on which Firefox runs) and in user-convenience (where it requires that they launch the executable prior to navigating to the webpage every time they want to run it, rather than allowing a one-off install into the browser as extensions do).
3. A local-file HTML tree, run via the file:// protocol. This won’t solve the service worker problem—it will, in fact be worse, since there’s no in-progress effort to add file://-protocol service worker support as there is for moz-extension:/—but it will solve the extension-background-scripts problem, with browser extensions being able to run background scripts on file:// pages without issue. This will come at the cost, however, of a great many inconveniences being inflicted upon you by the same-origin policy, as all local files are considered to be of different origins from one another.
4. A local executable with webview-based rendering. This frees you from many of the restrictions of the web browser, allowing much more versatile program behavior than the browser sandbox would permit. However, it comes with similar compatibility-related costs to those of the second option, and, moreover, it locks you out from browser extensions (not to mention even many pieces of native browser functionality) far more aggressively than even the browser-extension-page sandbox does.

Any one of these options—or staying the course with a browser extension, despite its associated limitations—might be the optimal path to take for a given project, depending on the nature of said project. But none is neatly superior to all the others.

Perhaps, one day, browsers will add support for some new system which does capture all the upsides of the browser-based options here with none of the downsides—installable apps which can be loaded from local files and henceforth be run as if from a webserver, without the extra APIs and sandboxing of extensions and without any need for internet access and/or local non-browser webservers—but that day is not now, and for the moment this horrible mess of tradeoffs is the best we’ve got.

Tags: Firefox, Architecture, Web Development