Add-ons and "Powered by Mozilla" Applications

All authors of third-party software based on Mozilla and using the extension manager hit the same problem: a lot, really a lot, of users try to install the add-on inside Firefox instead of the application the add-on is made for... I hit that issue in the past with Nvu, I hit it now with BlueGriffon, Instantbird people hit it too. The error still sits between the chair and the keyboard, but maybe we could fix it in this case: the Extension Manager could have a list of couples (appname, appid) of well-known Mozilla-based applications and report "Ooops, this is a not an add-on for Firefox but an add-on for <appname>. Please launch <appname> to install it". That would help really a lot...


1. On Monday 13 August 2012, 22:52 by Arv

What's the argument against passing the extension to the correct applications in the same way as with other files, such as PDFs.

2. On Monday 13 August 2012, 22:55 by Daniel Glazman

@Arv: "opening" an XPI file might be not implemented by these 3rd-party apps... They might even have no "Open" menu at all and therefore no command line option to do it.

3. On Tuesday 14 August 2012, 00:10 by Asa Dotzler

That seems like a strange solution, asking Firefox to keep a list of popular non-Firefox addons hardcoded so it can redirect to a hardcoded list of non-Firefox apps.

Why should Firefox maintain a list rather than just fixing the architecture of extensions to put the target app in the manifest somewhere and have all extension capable apps simply reflect that. "This extension is telling SeaMonkey that it is intended for BlueGriffon and will not work in SeaMonkey. To use the extension, you must install it into BlueGriffon."

4. On Tuesday 14 August 2012, 00:16 by starwed

>That seems like a strange solution, asking Firefox to keep a list of popular non-Firefox addons hardcoded so it can redirect to a hardcoded list of non-Firefox apps.

You misunderstood the post; this would be a hardcoded lists of application names, not addons.

Extensions currently target applications by a particular unique ID, and don't list a name. So for now, firefox could at least map the IDs to the name when giving an error.

5. On Tuesday 14 August 2012, 00:23 by Mook

Some extensions (e.g. DOM Inspector) are available for multiple applications; this wouldn't help with that.

For extensibility, it's probably more useful to drop files named by the application ids somewhere, e.g. /usr/lib/mozilla/applications/{ec8030f7-c20a-464f-9b0e-13a3a9e97384} being a symlink to /usr/lib/firefox/firefox-bin (or something along those lines). If the addon manager then came withe a --install-extension command line argument by default, that would work. (There would need to be a per-user area too, of course.)

This way 1) the browser doesn't need to know ahead of time what apps are available; 2) external applications that want to install things in Firefox can have a non-hacky way to do things (and Firefox would be free to implement whatever user-prompting it desires); 3) if desired, the user can even be prompted about which app to install into (since it can look at the list of supported apps, whether they are installed on the system, and their application.ini on disk to see if they're compatible).

6. On Tuesday 14 August 2012, 03:26 by tom jones

why doesn't your app register a bluegriffon:// protocol handler, and serve links to addons with that prefix..

7. On Tuesday 14 August 2012, 03:47 by clokep

You bring up an excellent point that we've run into before in Instantbird! The best idea we could come up with was using a different protocol and then registering the protocol with the OS (Adium does this with their adiumxtra links) so the links open automatically in Instantbird. If you think this is a reasonable solution, maybe we can work together on implementing it in a generic way for Instantbird and Blue Griffon (and anyone else who is interested!) Email me or stop by #instantbird on irc.mozilla.org. :)

--Patrick (:clokep), Instantbird developer and chat peer

8. On Tuesday 14 August 2012, 10:54 by Blair McBride

Thanks for bringing this up - it would be nice to be able to better help people dealing with this.

Like Asa, I don't really like the idea of having a hard-coded list of applications - it doesn't scale well, in terms of the maintenance cost for the Add-ons Manager (put another way, I don't want to have to do any maintenance at all). I think for it to work, applications themselves need to somehow advertise that they're available on the system, and can handle addons.

Mook and clokep have two different methods for doing that:
* Manifest file - this seems doable. There should be a location on each OS where we could put them. It'd result in doing I/O, but it's not something that needs to be read on startup. But it would mean potentially stale manifests after an app is uninstalled (mostly thinking of OSX here).
* Protocol handler - I'm not sure how this would work. When we see an addon, all we'd know is the app ID, which can contain characters that can't be part of a protocol name (the scheme component of a URI). As I said above, I don't want to have a list of ID->name mappings.

Another would be registering handling of a mimetype (eg, "moz-extension/<APPID>"). Not entirely sure how well that would work - it'd probably be ok on Windows, but not sure about OSX/Linux.

9. On Tuesday 14 August 2012, 13:29 by Daniel Glazman

@Blair: I don't expect you to do any maintainance of appids constants in your code!!! You could rely on an online resource like the Mozilla Apps Hall of Fame or something like that and extract the appids from there (please note the appids are not there yet but we could certainly add them into a "display: none" span for instance). If the online resource is reachable, get the appnames/appids from there and cache it; if not use the cache. That seems to me drastically simpler than any protocol-based solution (super-complex in case of multi-apps add-ons) and cleaner than a static manifest.

10. On Wednesday 15 August 2012, 04:06 by Blair McBride

The Apps Hall of Fame isn't setup to handle that kind of load, and if were to use something like that it needs to be via a proper (designed & supported) API, not a HTML document. But even so, I don't like the idea of pulling in even more remote data, especially when there can be a local-only solution.