Best way to perform some actions after installation/updating?
Nils Maier
carry out some actions once the extension was installed/updated.
I don't like the "check whenever the extension loads if it's a new
version" approach...
My current idea is to have a "fake" component installer; NSGetModule +
some module, that won't actually install components but instead carry
out necessary actions.
As I understand it FX/TB/XR will execute it whenever a new extension is
installed.
And updates are basically: uninstall old version and install new
version. So it should be triggered for updates as well, correct?
And it should be even possible to use this for "uninstall actions"
(unregisterSelf)...
So my question now is:
Has somebody already implemented run-once functionality via NSGetMdoule,
and how did if work out if so?
Is it possible to already e.g. modify preferences and/or display some
chrome UI at this point?
Is XPCOM fully initalized at that stage, or just some parts like
nsIComponentRegistrar, nsICategoryManager and other built-in components
might fail to "load"?
Or does somebody have a different and better approach?
Thanks for any comments (that probably will prevent me to do some work
that I have to trash later ;))
Nils
Nickolay Ponomarev
> I'm currently thinking on how to implement functionality, that will
> carry out some actions once the extension was installed/updated.
>
> I don't like the "check whenever the extension loads if it's a new
> version" approach...
>
Nickolay
Nils Maier
And why exactly?
And what do you mean by "appropriate"?
Honestly, simply saying "I prefer this" without giving any reasoning
doesn't help me much, as this doesn't answer my questions at all.
Thanks for answering anyway.
Nils
Nickolay Ponomarev
installation is somehow related to the moment of components
registration. IIRC, *all* the components of all extensions are
re-registered during 'auto-registration' which can be triggered
manually and also happens when a new XPI is installed or uninstalled.
Even if it wasn't so, components registration was not designed to do
install-time extension initialization steps not related to the
component itself, so (ab)using it in this way will likely cause you
trouble when the system is tweaked/optimized/rearchitected later.
It would be nice if the install manifest provided a way to run custom
code on install/uninstall, but in absence of that mechanism it's
better to use the common workaround everyone else is using than invent
something different just for the sake of being different. You never
said what exactly you disliked about the common workaround.
Nickolay
Nils Maier
Hash: SHA1
Nickolay Ponomarev wrote:
> You make this weird assumption that the moment of extension
> installation is somehow related to the moment of components
> registration. IIRC, *all* the components of all extensions are
> re-registered during 'auto-registration' which can be triggered
> manually and also happens when a new XPI is installed or uninstalled.
This is excatly the kind of comment I was looking for ;)
Your first reply didn't provide any information I was looking for, just
some general remark without any explanation, so it was simply of no use
to me.
It is actually an observation (I didn't verify).
At least .xpt is not not re-registered in FX2.0, even when touched.
I didn't check whether the actual component is re-registered though...
> Even if it wasn't so, components registration was not designed to do
> install-time extension initialization steps not related to the
> component itself, so (ab)using it in this way will likely cause you
> trouble when the system is tweaked/optimized/rearchitected later.
So even if this runs on every startup (re-registration) it is IMO better
than the other approach. (s.b.)
Should be possible to create an nsIOberserver listening to
"final-ui-startup", so that this doesn't look that hacky anymore.
Remember seeing this in nsBrowserGlue... Why didn't I think of this in
the first place :p
Question is: what happens first; component registration or that
notification?
My guess is the registration, but need to verify...
> It would be nice if the install manifest provided a way to run custom
> code on install/uninstall, but in absence of that mechanism it's
> better to use the common workaround everyone else is using than invent
> something different just for the sake of being different. You never
> said what exactly you disliked about the common workaround.
I do not "invent" stuff "just for the sake of being different".
I "invent" stuff that fits my needs.
What do you think is the reason I first asked the group? Right, to
explore possiblities.
Indeed, I didn't clarify my objections.
* It appears to be damn hacky.
* I want a common point of failure: It's a nice assumption that it's
enough to overlay the main window (e.g. browser.xul), but you never know
that this will be the actual codepath in all cases. Putting some
"boilerplate" code in front of each invokable codepath of the extension
is not a good thing either.
* Each overlay (to the main window) will slow down app-performance and
adds another point of failure.
* Performing stuff in the main window is always "fighting" with other
extensions which may behave not so well. Adding more code => more
possible issues/"attack surface".
* Executing stuff once is better than executing it over and over again.
* Bonus-point: you get your own sandbox :p
Any objections to "implement nsIObserver and listen to 'final-ui-startup'"?
Regards
Nils
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRfr6o4jDcu3WAa6VAQJ3UQf/Usjl68DPfRzJNI8CQjzfLEhPUcDXPPRP
TNjkR3xoV8aNIXuiYoA2UsvW24TPv0IhXLjV2JzLf7kGsabIBU/HI84S7+FMQFDh
1l6kmwY3fsh0NbCoBnq7iHi5MsHYT18XINl2ncaMyzpSLQOGnNIKSKwgVgmuvawL
Hve6YKgs4YmqrXS/1uSYkXEeamZ1/DviHt2dEu/JyFJ3A5ClxQ5MnGASiTTbpYbq
U/ZdhHKNRO5JnGmHjj8PkikT56/DBiCrpLAR8EnUxdvg6AncswJ+gnghs0c7MMMA
xaemPuxu92qo5q69vxBrkJrmhddAhN6c6v12/rkAJj95n1eLpTjqOw==
=Gp94
-----END PGP SIGNATURE-----
Nickolay Ponomarev
> It is actually an observation (I didn't verify).
> At least .xpt is not not re-registered in FX2.0, even when touched.
> I didn't check whether the actual component is re-registered though...
>
individual components or XPTs. You have to install and XPI or
create/touch certain file in the Firefox directory (.autoreg?)
> > Even if it wasn't so, components registration was not designed to do
> > install-time extension initialization steps not related to the
> > component itself, so (ab)using it in this way will likely cause you
> > trouble when the system is tweaked/optimized/rearchitected later.
>
> So even if this runs on every startup
This *is* the other approach.
> (re-registration) it is IMO better
And this is different, worse IMO, way to do this.
> than the other approach. (s.b.)
s.b. ?
> Should be possible to create an nsIOberserver listening to
> "final-ui-startup", so that this doesn't look that hacky anymore.
> Remember seeing this in nsBrowserGlue... Why didn't I think of this in
> the first place :p
> Question is: what happens first; component registration or that
> notification?
> My guess is the registration, but need to verify...
>
I think registration, xpcom-startup, app-startup. You can register an
app-startup observer via the category manager and indeed do your
initialization there.
> > It would be nice if the install manifest provided a way to run custom
> > code on install/uninstall, but in absence of that mechanism it's
> > better to use the common workaround everyone else is using than invent
> > something different just for the sake of being different. You never
> > said what exactly you disliked about the common workaround.
>
> I do not "invent" stuff "just for the sake of being different".
> I "invent" stuff that fits my needs.
> What do you think is the reason I first asked the group? Right, to
> explore possiblities.
> [snip]
>
So these appear to be reasons against 'do the check in the browser
window', not against 'do the check on every startup'.
> Any objections to "implement nsIObserver and listen to 'final-ui-startup'"?
>
Never heard about final-ui-startup, but doing this in app-startup
sounds reasonable, yes.
Nickolay
Nils Maier
Hash: SHA1
Nickolay Ponomarev wrote:
> On 3/16/07, Nils Maier <Maie...@web.de> wrote:
>> It is actually an observation (I didn't verify).
>> At least .xpt is not not re-registered in FX2.0, even when touched.
>> I didn't check whether the actual component is re-registered though...
>>
> Right, I don't think autoregistration is triggered by touching
> individual components or XPTs. You have to install and XPI or
> create/touch certain file in the Firefox directory (.autoreg?)
>
>> > Even if it wasn't so, components registration was not designed to do
>> > install-time extension initialization steps not related to the
>> > component itself, so (ab)using it in this way will likely cause you
>> > trouble when the system is tweaked/optimized/rearchitected later.
>>
>> So even if this runs on every startup
>
> This *is* the other approach.
>
>> (re-registration) it is IMO better
>
> And this is different, worse IMO, way to do this.
>
>> than the other approach. (s.b.)
>
> s.b. ?
s.b = See below.
(Disclaimer: I'm German, so the abbreviate might be plain wrong.)
>
>> Should be possible to create an nsIOberserver listening to
>> "final-ui-startup", so that this doesn't look that hacky anymore.
>> Remember seeing this in nsBrowserGlue... Why didn't I think of this in
>> the first place :p
>> Question is: what happens first; component registration or that
>> notification?
>> My guess is the registration, but need to verify...
>>
> I think registration, xpcom-startup, app-startup. You can register an
> app-startup observer via the category manager and indeed do your
> initialization there.
>
>> > It would be nice if the install manifest provided a way to run custom
>> > code on install/uninstall, but in absence of that mechanism it's
>> > better to use the common workaround everyone else is using than invent
>> > something different just for the sake of being different. You never
>> > said what exactly you disliked about the common workaround.
>>
>> I do not "invent" stuff "just for the sake of being different".
>> I "invent" stuff that fits my needs.
>> What do you think is the reason I first asked the group? Right, to
>> explore possiblities.
>> [snip]
>>
> So these appear to be reasons against 'do the check in the browser
> window', not against 'do the check on every startup'.
Best would be obviously to run just once, but, yes, more importantly I
don't want that code in the main window; browser for FX, but there might
be TB support later as well, or even Flock if they get/got a Gecko 1.8
platform.
Sorry for any miscommunication here.
>> Any objections to "implement nsIObserver and listen to
>> 'final-ui-startup'"?
>>
> Never heard about final-ui-startup, but doing this in app-startup
> sounds reasonable, yes.
final-ui-startup is a notification that is served by XRE_main.
For example nsBrowserGlue will observe it and run Sanitizer code (if it
wasn't run already because of an unclean shutdown).
> Nickolay
I still don't really see why doing stuff directly from |registerSelf| is
such a bad thing. Global component registration should be finished as
this point. And future incompatiblities may surface everywhere.
Anyway, if it is bad (practise), I'll take your word for it...
I'll go for an app-startup (+ final-ui-startup) implementation.
Thanks for commentary and help. :D
Nils
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRfvAkojDcu3WAa6VAQLiBAgAhdABVAquBvD7mJU51vPwGfDvf4no10My
5gMpHG53wsN+or7zw57jCHU9Mvun2Jgutud2hGgHelq72NsHVAOyiECjC58TpzXM
PvW7HmtP39SXrAiNN6pLG730MqaYuj+IieX7nUSf6pe1XqonjtwKUBmhJjjHhx/q
x8Hvwrv39GUUHepPftadngPfQJAAgX4/g9ssW+WSXMvUiGuqL+BeR/aWdZdsHTmA
+eyvR/vM6K6xMMRDb/3VMdFpKrbtQ7pYXH9/8uIQh15R6WKQjBJoMo2Mu2l/hoHh
B8BoTwINB0sgHBb4p3CUEHO+7fbGspjILHQPiVyLEr0USz8pGIv/tQ==
=7F8b
-----END PGP SIGNATURE-----
Nickolay Ponomarev
> I still don't really see why doing stuff directly from |registerSelf| is
> such a bad thing. Global component registration should be finished as
> this point.
I doubt XPCOM is fully initialized at that point, so you'll likely
have trouble using it, for one thing.
Nickolay