Closed
Bug 333049
Opened 18 years ago
Closed 8 years ago
Locking a complex preferences doesn't work properly
Categories
(Core :: Preferences: Backend, defect)
Core
Preferences: Backend
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mkaply, Unassigned)
References
Details
Attachments
(1 file)
708 bytes,
patch
|
benjamin
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
Easy to recreate Create a new profile. Go to about:config search on browser.startup.homepage right click - select "Lock" click on the home button. You get to see the source of browserconfig.properties. Problem is in prefbranch - this code: http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/nsPrefBranch.cpp#249 if the pref is locked, we assume it is not a complex value. This is simply wrong. locked prefs certainly can be complex values.
Reporter | ||
Comment 1•18 years ago
|
||
even with that change, this code is still broken. This whole "Guessing if we are a complex value" just seems wrong. Shouldn't we do something simple like look at the result of the getCharPref and if it begins with chrome: or res: assume it is a complex value?
Reporter | ||
Comment 2•18 years ago
|
||
incidentally, to see the other problem, after my fix is in, set the home page to http://www.yahoo.com in about:config, then lock the pref (note it reverts to a resource: url) then click home - junk.
Reporter | ||
Comment 3•18 years ago
|
||
OK, so here is the correct logic. If it is a locked preference OR if a user pref has not been set, assume it is a complex value. The only case where this won't work is if you try to set a non complex value as the default and lock it (for instance setting browser.startup.homepage to http://www.yahoo.com and then lock it) If a preference was a localized preference in the browser and you want to lock it, you have to lock it using a localized preference as well (for instance the CCK)
Comment 4•18 years ago
|
||
To do that you'd need pref("browser.startup.homepage", "data:text/plain,browser.startup.homepage=http://www.yahoo.com/");
Updated•18 years ago
|
Attachment #217486 -
Flags: superreview?(darin)
Attachment #217486 -
Flags: review+
Updated•18 years ago
|
Attachment #217486 -
Flags: superreview?(darin) → superreview+
Comment 6•16 years ago
|
||
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
Updated•15 years ago
|
QA Contact: preferences → preferences-backend
Reporter | ||
Comment 7•12 years ago
|
||
No idea why this got lost, but this is still broken. And the code is still current. Can I check in when I get my Hg state figured out?
Reporter | ||
Comment 8•8 years ago
|
||
After further research, I'm going to WONTFIX this. This patch would break locking a pref like this: "browser.startup.homepage", "data:text/plain,browser.startup.homepage=http://www.yahoo.com/" and this has kind of become the norm after all these years (because of this bug). So I think at this point, folks are accustomed to things being broke and any attempts to "fix" would break other things.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•