259273 - missing locale in user agent string

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Met - Martin Hassman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

In the user agent of FF1.0PR is missing locale

See:
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
and comare with Mozilla:
Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.7.2) Gecko/20040803

the "cs-CZ;" (or en-US or someting else) is missing in the FF1.0PR

Reproducible: Always
Steps to Reproduce:
You can see this in about: or in Help/About Mozilla Firefox, or on
http://www.alenka.cz/test/

Locale value if the UA-sting is stored in the pref general.useragent.contentlocale
Value of this pref is (defined in the all.js) in the
chrome://navigator-region/locale/region.properties

But is seems, that file chrome://navigator-region/locale/region.properties is
blank in the FF1.0PR

Comment 1

[Benjamin Smedberg]

dammit. I changed this pref from a localized pref to a regular pref, but the
networking code still expects a localized pref. Darin, can you think of an easy
way to fix this without adding #ifdef MOZ_XUL_APP?

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #1)
>Darin, can you think of an easy
> way to fix this without adding #ifdef MOZ_XUL_APP?

how about "if reading as localized pref fails, read as normal pref"?

Comment 3

[Darin Fisher]

biesi's suggestion sounds reasonable to me.

Comment 4

[Benjamin Smedberg]

> Locale value if the UA-sting is stored in the pref general.useragent.contentlocale

Actually, it is stored in general.useragent.locale, see
http://lxr.mozilla.org/aviarybranch/source/netwerk/protocol/http/src/nsHttpHandler.cpp#753

patch coming up

Comment 5

[Benjamin Smedberg]

Attachment: Make nsHttpHandler.cpp more forgiving

Comment 6

[Benjamin Smedberg]

Comment on attachment 158893 [details] [diff] [review]
Make nsHttpHandler.cpp more forgiving

Ignore this, it would be good if I actually build/tested patches before I
attached them.

Comment 7

[Benjamin Smedberg]

Attachment: whack nsHttpHandler, building and working this time

Comment 8

[Darin Fisher]

Comment on attachment 158895 [details] [diff] [review]
whack nsHttpHandler, building and working this time

>Index: nsHttpHandler.cpp

>+        if (NS_SUCCEEDED(rv) && pls) {

checking both |rv| and |pls| here is redundant.  you only
need to check |pls|.


>+        } else {

try to match existing bracket style:

	  }
	  else {


>+            nsXPIDLCString cval;
>+            rv = prefs->GetCharPref(UA_PREF("locale"), getter_Copies(cval));
>+            if (NS_SUCCEEDED(rv) && cval)

this also doesn't need to check |rv|.


r+sr=darin with those tweaks.

Comment 9

[Met - Martin Hassman]

Maybe stupid question. Is really a good idea to remove this from the localizable
prefs?

What about localization packages, or what about Linux users with switchable locale?

Is there any good reason for this change?

Comment 10

[Benjamin Smedberg]

> Maybe stupid question. Is really a good idea to remove this from the localizable
> prefs?

This is no longer a localizable pref because it *is* the locale-switching pref.
Whatever this pref is set to is the default locale of the browser.

Comment 11

[Benjamin Smedberg]

*** Bug 259536 has been marked as a duplicate of this bug. ***

Comment 12

[Simone Chiaretta]

Remember that this bug also generates another problem witn the DOM property
navigator.language also returns an empty string instead of en-US (or whatever)

Comment 13

[Asa Dotzler [:asa]]

Comment on attachment 158895 [details] [diff] [review]
whack nsHttpHandler, building and working this time

a=asa (on behalf of the aviary team) for checkin to the aviary branch.

Comment 14

[Benjamin Smedberg]

Checked in, branch and trunk.

Comment 15

[Guenter Huerkamp]

(In reply to comment #14)
> Checked in, branch and trunk.

working
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040916
Firefox/0.10 (Huerkamp)

Comment 16

[Bill Mason]

*** Bug 260176 has been marked as a duplicate of this bug. ***

Comment 17

[Mick Weiss]

I was going to post this to the duplicate (comment 16) 
...

[PASTE]

Mozilla works as expected:

My Mozilla UA String is:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040831
------------------------------
FireFox redirects to /FR:

My FireFox UA String is: 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913
Firefox/0.10
-------------------------------
Safari works:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.5 (KHTML, like
Gecko) Safari/125.9
-------------------------------
Camino also works:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040825
Camino/0.8.1
-------------------------------

I also tried to use the User Agent switcher (I couldn't figure out how to make
the UA String for Firefox, someone might want to try adding the en-US to see
what happens).

But I did try to change the UA String to that of Opera (Opera/7.54 (Windows NT
5.1; U) [fr]) <-- I changed it from "en" to "fr" to see if it would redirect to
the French site, and it redirected instead to the US one.

Another thing to note is that the Safari UA String didn't have any country code
set, yet it did redirect to /US.

Without the code from the ubisoft people, I'm unsure if it isn't just an issue
on their end. I know a few other sites use this type of redirect based on the
user's browser - I have to find another one and see how it responds.

Comment 18

[Eric Portelance]

Not sure if this is related to this bug, but since it was checked in, Wikipedia
always seems to default on the german language site for me.

Comment 19

[Peter van der Woude [:Peter6]]

*** Bug 263451 has been marked as a duplicate of this bug. ***