`cfx run` and require('self').loadReason

Showing 1-2 of 2 messages
`cfx run` and require('self').loadReason Myk Melez 12/31/12 12:33 PM

When you run an addon with `cfx run` against an existing profile with
the addon already installed, require('self').loadReason is set to
*startup*.  But `cfx run` reinstalls the addon, so it seems like
loadReason should be set to *upgrade*, so the addon knows to do tasks it
would normally do after being updated.

(This happens to cause a problem when running the Firefox OS Simulator,
which bundles a Gaia profile, tracks a set of apps the user has
installed in it, and reinstalls the apps into the new Gaia profile when
the addon is updated.)

I also notice that it isn't possible to run the addon with the *install*
loadReason, as `cfx run` on a new profile still sets loadReason to

Ideally, I would want to be able to run an addon with any of the load
reasons, but especially *install*, *startup*, and *upgrade*. Perhaps the
JS version of cfx (bug 631470) will fix this, or at least make it easier
to fix?

One thought for how to expose this functionality is that running `cfx
run` on a new profile could set loadReason to *install*; running it on
an existing profile could (continue to) set it to *startup*; and running
it on an existing profile with an active session could update the addon
in the existing session and set it to *upgrade*.

Alternately, perhaps it would be better to make this more explicit and
have a --loadReason command-line option to `cfx run` that sets it to the
desired value, which users could use with either an existing or a new


Re: `cfx run` and require('self').loadReason Dave Townsend 1/2/13 2:13 PM
This is a bug in Firefox not sending the correct information to restartless add-ons in some cases (https://bugzilla.mozilla.org/show_bug.cgi?id=607818). We might be able to work around it in the SDK's side by using the information sent in the install event rather than the startup event though.