Startup conflict/race with language packs causes incorrect Accept-Language headers after restart

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Ensure language settings are English GB in Firefox Preferences.
2. Install Firebug.
3. Open www.google.co.uk.
4. Start Firebug.
5. Hit F5.
6. View the Request Header in Firebug.
7. It shows "en-gb, en" in the Accept-language header.
8. Install jsonovich and re-start Firefox.
9. Repeat steps 3 to 6.
10. It shows "en-us, en" in the Accept-language header.

What is the expected output? What do you see instead?
It should still show "en-gb, en", I wouldn't expect the plug-in to affect that.

What version of the product are you using? On what operating system?
Ubuntu 10.04, Firefox 7.0.1, Jsonovich 1.9.0.1.

Original issue reported on code.google.com by phill.lu...@gmail.com on 7 Oct 2011 at 10:58

[GoogleCodeExporter]

Thanks for the report, I don't experience this on Windows and you are correct 
that Accept-Language should not be affected.

With the same Firefox and JSONovich versions, Firebug shows my Accept-Language 
as "en-gb,en;q=0.5" so I'm not quite sure what could be going on if yours is 
different before and after installation.

For what it's worth, restarting after installation is not necessary, JSONovich 
uses newer techniques that allow that possibility - are you sure the language 
settings are in effect after the restart?

If it makes any difference, Firebug I used is 1.8.3. I'm still not near my 
testing machine, but when I get to it I'll try again to reproduce. Do you have 
any other addons apart from Firebug and JSONovich when this happens? (Ans if 
so, does it still happen with them all disabled?)

Original comment by W.Elwoo...@gmail.com on 8 Oct 2011 at 9:40

[GoogleCodeExporter]

Just done some more testing.

A re-start is required before the problem begins, although the add-on page 
doesn't indicate that one is needed.

I disabled all add-ons including Firebug, except the English GB language pack 
(which is what defaults the language to en-GB), and re-tried. Enabling 
Jsonovich and nothing else triggers the problem. I was able to test with 
Firebug disabled by calling an ASP.NET test application locally.

Here's the original bug I filed against FF in Ubuntu if it helps. 
https://bugs.launchpad.net/bugs/867753

Original comment by phill.lu...@gmail.com on 9 Oct 2011 at 10:28

[GoogleCodeExporter]

Hi again, I just disabled all my addons on my Win7 Firefox 7 testing profile 
and installed all your app-profile addons listed on the launchpad bug, still no 
success getting my Accept-Language to change from "en-gb,en;q=0.5". Disabled 
everything but JSONovich, again no header change. I don't have any language 
packs to disable, I usually download the en-gb Firefox installer and I can't 
find any reference to an English GB language pack on addons.mozilla.org - is 
that something Ubuntu-specific with source code viewable online?

The fact that a restart is required to cause the problem suggests to me that 
JSONovich is not (solely?) at fault - JSONovich's startup code is exactly the 
same at install time, at browser startup and at any manual enable (a product of 
the restartless installation system of Firefox 4+). There is a single request 
observer registered which only touches the "Accept" header and only does so 
when a preference exists for the request host instructing it to do so, as soon 
as JSONovich is shutdown or disabled the observer is unregistered. After 
confirming the problem is in effect, perhaps it's worth disabling JSONovich 
without restarting and checking if the problem persists?

Otherwise I have to assume this is related to Ubuntu itself or the way Firefox 
gets built for it. Unfortunately further testing may be difficult for me, my 
Ubuntu machine is a headless server and I don't currently have room for a 
virtual machine without spending time consolidating space. Consequently I don't 
think I'll be able to offer a fix to this myself before the next release of 
JSONovich - patches from anyone capable of reproducing are always welcome of 
course.

Original comment by W.Elwoo...@gmail.com on 11 Oct 2011 at 2:37

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Thanks for looking into this further. I've done some more experimenting based 
on your post and it appears to be the way the defaults are handled.

The GB Language Pack appears to change the default "accept-language" (i.e. in 
about:config it says it's the default) setting to "en-GB" from "en-US" which is 
the default value without this pack installed. My OS settings are "en-GB" but I 
don't think they're automatically respected by Firefox on linux without the 
language pack. If I manually set the languages to "en-GB, en" the plug-in works 
fine. So I guess it's just a question of where the defaults are coming from.

I think the language pack is out-of-the-box on linux as I can't find a separate 
download. I'll ask the developers and get back on this.

I'm unfamiliar with the firefox plugin API, but if you point me in the right 
direction I might have a stab at debugging it sometime. No worries though, it's 
not a priority for me either.

Original comment by phill.lu...@gmail.com on 11 Oct 2011 at 12:16

[GoogleCodeExporter]

Thought you might want to know that the cause of the problem has been found 
within Firefox. Here's the link again for convenience 
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/867753, and 
https://bugzilla.mozilla.org/show_bug.cgi?id=693687.

Original comment by phill.lu...@gmail.com on 11 Oct 2011 at 7:16

[GoogleCodeExporter]

Cheers for the update!

I'm not sure I see anywhere that JSONovich causes initialisation of 
nsHttpHandler at startup (and even if it did, that handler seems to set up a 
preferences observer that would detect intl.accept_languages changing if the 
language pack was loaded after), but then I'm no expert on Firefox's startup 
routine.

If you're still interested in debugging to find which part of JSONovich 
triggers the problem, you can open the jsonovich@lackoftalent.org.xpi file that 
should be in your profile's extensions directory (it's just a zip file). First 
thing I'd try is commenting out everything inside the startup functions in 
modules/chrome/jsonovich.js and modules/content/jsonovich.js - that should 
break JSONovich, if the problem is no longer triggered then start uncommenting 
from the top down to see which require'd module triggers it. If the problem 
does still occur after commenting both the startup functions completely, you 
can repeat the process on the startup function in bootstrap.js - the message 
manager stuff can be ignored here since it only activates in Firefox 9+. I'd be 
very surprised if all of that didn't at least identify a line that triggers the 
problem.

Don't worry if you're not comfortable getting your hands dirty in the code, 
hopefully the Ubuntu people can get a fix out - it'll still bug me though so if 
they don't have a fix by the time I'm in a position to reproduce I'll be back 
here to follow my notes. :)

Original comment by W.Elwoo...@gmail.com on 12 Oct 2011 at 1:06

• Changed title: Startup conflict/race with language packs causes incorrect Accept-Language headers after restart
• Added labels: OpSys-Ubuntu

[GoogleCodeExporter]

Stop the presses! After all that typing, I realised that although I didn't find 
an English GB language pack there were others - after installing the pt-BR 
language pack and the locale switcher into my en-GB Firefox, I have managed to 
reproduce the issue on Windows. :)

I've narrowed down to the problematic code, it shouldn't have been executing at 
startup anyway - expect a fix shortly.

Original comment by W.Elwoo...@gmail.com on 12 Oct 2011 at 2:12

• Changed state: Accepted
• Removed labels: OpSys-Ubuntu

[GoogleCodeExporter]

Fixed in r160, thanks again for the report. This will be included in the next 
release some time before Firefox 8's release, which is scheduled for November 
8th.

Original comment by W.Elwoo...@gmail.com on 12 Oct 2011 at 2:35

• Changed state: Fixed

[GoogleCodeExporter]

Brilliant. Thanks for all your effort.

Original comment by phill.lu...@gmail.com on 12 Oct 2011 at 5:35