[WebExtensions] Future of innovative add-ons

Continuing the discussion from Proposal: native.js to "embrace & extend" the WebExtensions API:

This is the new general thread to discuss the changes in Firefox and how to continue developing really interesting add-ons. Especially WebExtensions and e10s are important.


By the way, we (Desktopd Project) are working heavily on the unpublished development versions of Zombie Navigator, a Firefox-specific automation add-on with headless (unattended mode) support:
https://addons.mozilla.org/en-US/firefox/addon/zombie-navigator/

Zombie Navigator is specifically developed to fill a gap among PhantomJS (WebKit) / SlimerJS (XULRunner), Selenium (WebDriver) and Greasemonkey (add-on).
It automates browsing sessions like SlimerJS or Selenium, and allows running content scripts like Greasemonkey too. It intends to support enterprise Firefox automation needs and at the same time be safe for new users.

But it intentionally has some restrictions by design (or some will be introduced in the future), mainly for security and privacy:

  • Greasemonkey-like content scripts are limited to tabs opened by the automating script (Zombie script / session script). Unlike Greasemonkey, there is no installation for a Zombie script. This also means that no script is injected into normal tabs the user opens manually. This is because the add-on is for automation but not customization of the browser.
  • Unlike Greasemonkey, unsafeWindow global is not available in content scripts
  • Command-line invocation can be disabled in preferences
  • No persistent storage is offered specifically for Zombie scripts (which means easier support for Private Browsing)
  • The monitoring tab shows what the script is doing with the APIs and this is not suppressable
  • Will use a separate set of SDK objects for each script (for better isolation and control, to make the stop button more reliable). We will use nested sandboxes for this
  • more…

In the coming releases, we will focus on security, safety and stability, as well as new features. We will document the security models, limitations, and warnings.

We have the following specific needs for Add-on APIs:

  • Read environment variables
  • Run a user-supplied script in a sandbox with our APIs exposed (yes, we don’t want to break APIs unnecessarily), in a CommonJS-like environment (we currently use toolkit/loader with special paths and a resolve callback)
  • Inject a contentScript string into a tab (because this is necesarily dynamic) This is safe thanks to special methods used in the add-on. (Modeled after SlimerJS’s API in fact)
  • Monitor preferences changes: especially file selection dialogs and action button in simple-prefs
  • Open the add-on’s preferences page at about:addons programmatically
  • Ability to mirror the appearance of Firefox in add-on UIs, also considering (complete) themes (i.e. include CSS and image files from chrome://)
  • Want to show the add-on name in the address bar (without a lock icon of course) in add-on pages to prevent fishing/spoofing. (Similar to “This is a secure Firefox page”, but without the Firefox icon) There should be an API for this (there is gIdentityHandler).
    • Unknown:
    • HTTPS (EV):
    • Firefox:
    • Add-on mockup:
  • Want to use Downloads.jsm functionality with downloads manager integrated
  • Want to save pages as PDF
  • Want to take screenshots of tabs
  • Want to hide its resource:// files from Web (see https://discourse.mozilla-community.org/t/efficient-method-to-script-embedded-pages-in-an-addon/7353/6)
  • Want to suppress/dismiss modal dialogs
  • Want to monitor its own network activity (to display a nice table to the user, as well as APIs)
  • Want to handle delegates from other add-ons (if explicitly enabled)

We need to support the oldest supported ESR version at all times (so cannot use WebExtension for a while). We would also like to support Seamonkey if possible.
We support signing-enforced official versions of Firefox as well as builds on exotic architectures / OSes and 3rd party products based on Firefox. Development is on GNU(/Linux) systems only.

1 Like

About native.js: isn’t it making it harder to deploy Firefox profiles in a headless server? (i.e. if Zombie Navigator depended on a native.js extension, which must be installed manually, it would invalidate some of the addon’s use cases.)

How about the low-level APIs in the SDK?
https://discourse.mozilla-community.org/t/help-extension-broken-again-in-firefox-developer-edition-nightly/7731/8?u=desktopd

Of course, a Rust-based secure sandboxed type-safe browser with all the Mozilla ideas (user control, privacy, customization) will certainly kill Chromium/Chrome!

Good things for Mozilla

  • Servo (Rust)
  • Browser.html
  • PDF.js
  • Shumway
  • asm.js
  • Some ideas from BrowserID (Persona)
  • Extended private browsing mode (anti-fingerprinting)

The problem is, what about add-ons? Moving to a new platform will likely break Add-on SDK, which means by that time all the intersting add-ons must be WebExtensions ready. (Though that will not happen very soon)


Using only high-level APIs in Add-on SDK is not perfect too. We have such an add-on: ClickGuard
https://addons.mozilla.org/en-US/firefox/addon/clickguard/
The problem here is mostly about support for anything other than desktop Firefox. Most prominently, UI related SDK modules do not work at all on Fennec. Neither do they on Seamonkey. This means one of the SDK’s main (perceived) goals is not met.

For this reason, we strongly hope that WebExtensions have (mostly) complete support for Fennec, Seamonkey, and Thunderbird. (B2G is inherently interesting too.)

Many add-on developers want to support ESR (and many derivatives based on ESR), Fennec, Seamonkey or Thunderbird. So please don’t deprecate older technologies until support for those platforms is working in WebExtensions.

1 Like

Firefox

SeaMonkey

@number12345 whilst I can’t comment on compatibility with the five extensions that you mention, I do know that some of the gems that became legacy for Firefox remain good with SeaMonkey.

Some of the extensions that are not immediately compatible can be successfully fed through this service:

Extension Converter for SeaMonkey

I’ll find, or begin, a separate topic to list the converted extensions that are good for me.

:+1: – thanks – and I assume that if SeaMonkey progresses to support a subset of WebExtensions APIs, the progress will not preclude reasonable use of other types of extension.