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,
unsafeWindowglobal 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/loaderwith special paths and a resolve callback) - Inject a
contentScriptstring 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:addonsprogrammatically - 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:
- Unknown:
- Want to use
Downloads.jsmfunctionality 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.
ā 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.