Comment 13 for bug 867753

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.