693687 - Can't access complex preferences from a bootstrapped addons startup() function [caused by JSONovich]

Status: VERIFIED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[Chris Coulson]

Ok, I'm not sure the bug title is entirely appropriate, and I'm not sure whether the addon manager is the appropriate place for this bug.

This was initially reported at https://launchpad.net/bugs/867753

This started off when the reporter stated that the Accept-Language header in all of their outgoing http requests was set to the wrong value ("en-us,en;q=0.5"), despite the fact that intl.accept_languages was set to the correct value according to about:config ("en-gb, en"). This is set to a complex value, with the real value coming from the reporters en-GB language pack addon.

We initially suspected that the bug was due to the JSONovich addon, as the problem was resolved after disabling that addon. However, further investigation has shown that JSONovich doesn't appear to be doing anything wrong.

Note, than JSONovich is a bootstrapped extension.

What appears to be happening is that something in it's startup() entry point triggers the initialization of the nsHttpHandler service, and nsHttpHandler reads and processes the value of intl.accept_languages at this point. However, when this happens, no extension chrome has been loaded - so the value ends up being provided by the built-in en-US provider instead.

So, it seems that it currently isn't possible to reliably read complex prefs from anything which runs inside the startup() function.

Comment 1

[Chris Coulson]

Hmmm, so actually, I guess that this is where the problem occurs:

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsXREDirProvider.cpp#715

Comment 2

[Dave Townsend [:mossop]]

The startup method is called early in startup, before chrome for non-restartless add-ons is registered. That is the problem here.

There are really only two solutions. One is to move the startup call to later in startup, the other is to have JSONovich fixed so it doesn't initialize nsHttpHandler until later in startup. The former has the potential to break existing add-ons as well as potentially make it harder to do certain tasks so I'd tend to side with just notifying the JSONovich author and leaving this as-is.

I would note that while startup() is called early it is still much later than non-restartless add-ons used to be able to be called, they could hit exactly the same problem if they weren't careful about delaying things they did to later in startup.

Comment 3

[Will Elwood (:Will)]

I have just committed a fix to JSONovich for this, I was unintentionally calling Services.io.newURI('http://...') at startup due to a silly mistake decrementing a counter too early.

Apologies for the noise.

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Thanks for the quick response!