Closed Bug 409725 Opened 16 years ago Closed 16 years ago

general.useragent.locale is busted


(SeaMonkey :: Preferences, defect)

Not set


(Not tracked)



(Reporter: neil, Assigned: neil)



(Keywords: regression)


(1 file)

This used to be a localised pref but under Toolkit it's now a regular pref.
where can one see that it's busted? It seems to work fine for me...
I thought there were more consumers, but I was mistaken.

nsInternetSearchService actually retrives the locale from
chrome://global/locale/ ... I guess that still works.

pref-locales.xul is dead anyway.

sidebarOverlay.js has bug 409780.

So that just leaves the redundant entry in to remove.
Assignee: prefs → neil
Attachment #294662 - Flags: review?(kairo)
umm, why do we duplicate so much stuff in and IMHO, we should clean up that duplication before doing a release, it doesn't look very healthy to me...

And should actually get the pref instead of, which is hardcoded to en-US.

Anyways, the part of cleanup attached here look good to me by code inspection (I have no build environment where I am currently, so can't test myself).
Attachment #294662 - Flags: review?(kairo) → review+
Target Milestone: --- → seamonkey2.0alpha
No longer blocks: 409780
Depends on: 409780
(In reply to comment #2)
> sidebarOverlay.js has bug 409780.

The patch there will remove that use.


Comment on attachment 294662 [details] [diff] [review]
Proposed patch
[Checkin: Comment 6]

1.101	2007-12-27 13:59	 	Remove obsolete property b=409725 r=KaiRo
Attachment #294662 - Attachment description: Proposed patch → Proposed patch [Checkin: Comment 6]
Closed: 16 years ago
Resolution: --- → FIXED
[Ah, "Mid-air collision detected!";
Neil, what about the following ?]

Last case to fix, per comment 4:

    * line 257 -- rv = prefs->GetCharPref("general.useragent.locale", getter_Copies(locale));

    * line 4626 -- intlBundle->GetStringFromName(NS_LITERAL_STRING("general.useragent.locale").get(),

    * line 143 -- #define SELECTED_LOCALE_PREF "general.useragent.locale"
Serge, we are supposed to use that pref, it's still the place that defines what locale we are using, it's just that it's defined directly as a pref now! See

Neil, (I asked KaiRo, who replied to ask you...)
I'm not sure I understand Kairo's comment 8.
I thought from his comment 4 that nsInternetSearchService.cpp/GetStringFromName should be updated to work like nsBrowserDirectoryProvider.cpp/GetCharPref.
Should it ? Or is it good to stay as it is ?

well, what GetStringFromName returns is the displayed locale, rather than the requested locale, which I guess is what GetCharPref would return

Obviously, I know too little to understand if that means whether our code/call should be kept or modified ;-/
(In reply to comment #9)

I filed bug 441816 too...
You need to log in before you can comment on or make changes to this bug.