Closed
Bug 81766
Opened 23 years ago
Closed 23 years ago
intl.accept_languages initially set to "chrome://navigator/locale/navigator.properties"
Categories
(SeaMonkey :: Preferences, defect)
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: drbrain-bugzilla, Assigned: ftang)
Details
If I want to read out the languages that the user is allowing themeselves to recieve (as set in Prefs | Navigator | Languages) I will get back "chrome://navigator/locale/navigator.properties" as an initial value rather than an actual language encoding. How to reproduce: function getPref() { var pref = null; try { pref = Components.classes["@mozilla.org/preferences;1"].getService(); if (pref) pref = pref.QueryInterface(Components.interfaces.nsIPref); } catch (e) { debug("getPref(): we caught exception \"" + e + "\" getting pref"); throw(e); } return pref; } dump(getPref().CopyCharPref("intl.accept_languages")); Expected Results: The display of "en-us" in the console (depending on localization preferences). Actual Results: The display of "chrome://navigator/locale/navigator.properties" in the console If it is desired I could probably whip up a package to demonstrate this code as it needs to be installed as part of Mozilla.
Assignee | ||
Comment 2•23 years ago
|
||
call getLocalizedUnicharPref instead.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 3•23 years ago
|
||
mass verification of Invalid bugs: to find all bugspam pertaining to this, set your search string to "MagaritaLuisaChascarilloAvoidsInvalidBugs". if you think this particular bug is *still* an open issue, please make sure of the following before reopening: a. where relevant, do check that it's actually still a problem with ***recent trunk builds*** on the all appropriate platform[s] b. provide clear, compelling reasons why this bug should be considered a valid one.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•