631470 - cfx pre-installs addons (like XUL add-ons), making real-world testing of restartless add-ons not possible

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Dietrich Ayala (:dietrich)]

in real life, add-ons built from the sdk trigger events when they're installed. however, because cfx pre-installs add-ons in a new profile, the events do not get triggered and Firefox does not respond in the way it would in a typical add-on installation scenario.

one option is to have cfx start up firefox and then install the add-on after the browser is fully up.

Comment 1

[Atul Varma [:atul]]

As a historical note, this is actually the reason I made "cfx develop", but that never got very polished. "cfx develop" was written before restartless addons actually existed, though, so it uses one addon that transplants its own brain every time the addon is refreshed (via a 'cfx run --use-server' from another shell).

Add-ons developed using the Add-on Builder provide the most "realistic" experience here, since they actually create a real XPI and install it restartlessly.

That said, another route to fix this bug might be to rework 'cfx develop' to use restartless addons, though that potentially complicates the user experience (since it makes people have to choose between 'cfx develop' and 'cfx run').

Comment 2

[Dietrich Ayala (:dietrich)]

The default experience should mimic as closely as possible what actually happens when a user installs their add-on. Otherwise you get "launch day surprises".

Hmm, here's an idea: what about doing what FD does? cfx could pre-install the fdhelper add-on and then it'd do whatever FD does from that point.

Comment 3

[Atul Varma [:atul]]

Aye, this is really just happening because cfx was made before restartless addons were possible, so at the time, 'cfx run' was very close (if not identical to) the actual behavior of installing addons.

Replicating what FD does is one possibility, but because it too was created at a time before restartless addons existed, it's a bit wonky itself.

Another solution may be to actually have 'cfx run' install two addons--one being a "test harness" that is pre-installed, but which then installs the "real" addon restartlessly.

One thing I'm realizing as I think about this, though, is that we really have more "real-world" conditions to test: sometimes a user may be starting Firefox for the first time, and things in the Jetpack platform (or in third-party libraries) might behave differently then than they do when the user has already had Firefox running and decides to enable/disable/install a restartless add-on. So providing a way for add-on developers to try out both scenarios easily could be ideal, and currently the best way to do this without changing the SDK, I think, is by simply telling authors to use 'cfx run' to simulate one case, and using "enable/disable" on the Test App/Add-on during 'cfx run' to simulate the other.

Comment 4

[Dietrich Ayala (:dietrich)]

The latter option is a pain, as Drew pointed out in the bug that caused me to file this, which I can't remember the number of offhand.

If there's a regular AOM API for silent restartless install that the builder-helper addon uses, I can just use that, and maybe implement a "cfx install" option.

Comment 5

[Dietrich Ayala (:dietrich)]

Atul, how exactly does cfx run install the add-on now? Dave was wondering how you did that in such a way that the proper events weren't sent out.

Comment 6

[Atul Varma [:atul]]

(In reply to comment #4)
> If there's a regular AOM API for silent restartless install that the
> builder-helper addon uses, I can just use that, and maybe implement a "cfx
> install" option.

Nope, there isn't--this is part of why the ABH add-on is wonky... The ABH add-on itself is restartless and must be manually installed by a user, but the XPIs that the ABH installs actually bypass the AOM entirely--the ABH effectively has its own "add-on manager" built into it, in a weird way.

However, if there is a way to silently install a restartless addon via a supported AOM API, we should probably move to it, so that the proper events are sent out... I think. The reason the ABH works as it does is b/c, like 'cfx', it was created before the era of restartless addons, so it had to provide restartless addon functionality on its own hacky way. :/

Comment 7

[Atul Varma [:atul]]

(In reply to comment #5)
> Atul, how exactly does cfx run install the add-on now? Dave was wondering how
> you did that in such a way that the proper events weren't sent out.

Actually, we just delegate to MozRunner for this, and I'm not really sure how MozRunner does it. We just tell MozRunner "yo, start a new profile with this funky addon installed in it" and it does that. I suspect MozRunner just does this by adding the extension to the 'extensions/' directory of the user profile directory, but I'm not sure.

Comment 8

[Dave Townsend [:mossop]]

(In reply to comment #6)
> (In reply to comment #4)
> > If there's a regular AOM API for silent restartless install that the
> > builder-helper addon uses, I can just use that, and maybe implement a "cfx
> > install" option.
> 
> Nope, there isn't--this is part of why the ABH add-on is wonky... The ABH
> add-on itself is restartless and must be manually installed by a user, but the
> XPIs that the ABH installs actually bypass the AOM entirely--the ABH
> effectively has its own "add-on manager" built into it, in a weird way.

Uhh really? Is that because you want to hide the test add-ons from the add-ons manager or something?

> However, if there is a way to silently install a restartless addon via a
> supported AOM API, we should probably move to it, so that the proper events are
> sent out... I think. The reason the ABH works as it does is b/c, like 'cfx', it
> was created before the era of restartless addons, so it had to provide
> restartless addon functionality on its own hacky way. :/

There is totally an API you can call to silently install add-ons into Firefox. AddonManager.getInstallForURL followed by calling install() on the passed back AddonInstall should do the trick.

(In reply to comment #7)
> (In reply to comment #5)
> > Atul, how exactly does cfx run install the add-on now? Dave was wondering how
> > you did that in such a way that the proper events weren't sent out.
> 
> Actually, we just delegate to MozRunner for this, and I'm not really sure how
> MozRunner does it. We just tell MozRunner "yo, start a new profile with this
> funky addon installed in it" and it does that. I suspect MozRunner just does
> this by adding the extension to the 'extensions/' directory of the user profile
> directory, but I'm not sure.

I can't think of any way to get a restartless extension into a profile without it having the usual install method called on it so if this is happening it would be useful to know.

Comment 9

[Atul Varma [:atul]]

(In reply to comment #8)
> > Nope, there isn't--this is part of why the ABH add-on is wonky... The ABH
> > add-on itself is restartless and must be manually installed by a user, but the
> > XPIs that the ABH installs actually bypass the AOM entirely--the ABH
> > effectively has its own "add-on manager" built into it, in a weird way.
> 
> Uhh really? Is that because you want to hide the test add-ons from the add-ons
> manager or something?

It was originally simply because it was the only way to make an addon restartless, because it was made before restartless AOM functionality was added to the platform. But I believe that even after that, it was still necessary because Myk wanted to retain the behavior whereby when Firefox was restarted, the add-on being developed on ABH would be automatically uninstalled. (This is actually just a happy coincidence of the ABH, since the ABH maintains no persistent information about what addon is currently installed.)

> There is totally an API you can call to silently install add-ons into Firefox.
> AddonManager.getInstallForURL followed by calling install() on the passed back
> AddonInstall should do the trick.

Cool. I guess to retain the behavior I mentioned above, the ABH should also silently uninstall the add-on when Firefox shuts down...

Comment 10

[Alexandre Poirot [:ochameau]]

I used this API for my cfx javascript tool in order to run addons in the same firefox instance.
Then with a remote firefox instance we can built a "pre-installed" extension that will use this API to install the addon like in real world.
But there is one drawback about using this API: this is slow! There seems to be some timeout in it.

Comment 11

[Myk Melez [:myk] [@mykmelez]]

(automatic reprioritization of 1.0 bugs)

Comment 12

[Alexandre Poirot [:ochameau]]

If we finally implement this, we would be able to remove unnecessary code in widget:
https://bugzilla.mozilla.org/show_bug.cgi?id=627484#c41

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to Atul Varma [:atul] from comment #6)
> (In reply to comment #4)
> the ABH effectively has its own "add-on manager" built into it, in a weird way.

This is no longer true with some of the not-quite-recent changes to ABH, right, Alex? I see my Builder-based addons listed in the addon manager.

Maybe it's time to revisit this bug?

Comment 15

[Alexandre Poirot [:ochameau]]

This bug is not about Addon builder but about cfx.
You are right, it works fine with ABH, but we still preinstall addons in cfx.

That would be easy to fix in cfx-js branch as I already implemented an install-xpi command: 
https://github.com/mozilla/addon-sdk/blob/cfx-js/cfx/cfx.js#L29

Doing it in cfx-py would mean installing an helper addon that would install the jetpack addon to test/run. More or less what we are doing with cfx-js...

Comment 17

[Erik Vold [:erikvold] (please needinfo? me)]

Sorry we won't be releasing any new versions of cfx, jpm is the replacement https://www.npmjs.com/package/jpm

With jpm it's easy to create a node script to do this, we might build the feature in but we are trying to keep it minimal.