Closed
Bug 161751
Opened 22 years ago
Closed 19 years ago
Unable to change theme when capability lines are added to prefs.js
Categories
(Core Graveyard :: RDF, defect)
Core Graveyard
RDF
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: brad, Assigned: neil)
Details
Attachments
(1 file)
2.10 KB,
patch
|
benjamin
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020807 BuildID: 2002080718 When the following lines are added to prefs.js, I am unable to change the Mozilla theme. --- cut here --- user_pref("capability.principal.codebase.p0.granted", "UniversalPreferencesWrite UniversalXPConnect UniversalPreferencesRead"); user_pref("capability.principal.codebase.p0.id", "http://mozilla-evangelism.bclary.com"); --- cut here --- Entering these lines manually or having the Mozilla evangelism sidebar add them causes the behavior. I've verified this with a new profile. Reproducible: Always Steps to Reproduce: 1. Change the Mozilla theme a few times. Note that it works properly. 2. Exit Mozilla. 3. Add the given lines to prefs.js. 4. Start Mozilla. 5. Try to change the theme. Note that upon restarting Mozilla, the theme is not changed. Actual Results: The theme is not changed. Expected Results: The theme should change. I've seen this with all recent builds, with my existing profile, and with new profiles.
Comment 1•22 years ago
|
||
reporter (Brad): can you still reproduce this bug with a recent build of mozilla? if so, please comment again with details. if not, please resolve this bug as WORKSFORME. thanks.
Unfortunately, yes -- I can still reproduce it. I tried 1.2b (2002101612) and the latest nightly (2002110308). . I shut down Mozilla. . I added the two lines shown in the initial bug description to prefs.js (of course, I replaced the two extra newlines with spaces). . I started Mozilla again. . I attempted to change themes using View->Apply Theme->(new theme). It said, "Theme changes will take effect when you restart Mozilla." . I closed Mozilla. . I restarted Mozilla. The theme had not changed. When I close Mozilla, remove the two lines from prefs.js, and restart Mozilla, theme changing works as expected.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug is also present in the 1.6 release. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
This bug is also present in 1.7 and 1.8a1 (UA strings appended). As I see this on the Mac may I suggest changing this bug's Hardware and OS setting to "All"? Note that the Mozilla Evangelism sidebar is now known as the bclary sidebar and is available at <http://bclary.com/2004/06/06/sidebars>. The user_pref("capability.principal.codebase.p0...); lines in the prefs file are inserted when the user requests Mozilla to remember the permissions granted to change the the UA string from the sidebar. Also note that a google search shows that other sidebars and applications use the "capability.principal.codebase" pref, so this problem (while probably not widespread) isn't isolated to a single sidebar. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520
Assignee: shliang → neil.parkwaycc.co.uk
OS: Windows 2000 → All
Hardware: PC → All
Assignee | ||
Comment 5•20 years ago
|
||
Weird... this works fine for me on my Linux debug, but not on Windows...
Assignee | ||
Comment 6•20 years ago
|
||
Here's the deal: caps has a pref callback for capability.principal That callback sees at "http://mozilla-evangelism.bclary.com" and creates a new URI via the IO service to the HTTP protocol handler. Now the HTTP protocol handler wants to create the UA string, so it reads a bunch of prefs including the general.useragent.locale pref, which is a localized pref whose default is stored in chrome://navigator/content/navigator.properties This then invokes the chrome registry, which notices that the profile has changed and therefore tries to switch skin. But because we're still reading preferences the skin pref hasn't been read yet.
Assignee: neil.parkwaycc.co.uk → darin
Component: Themes → Networking: HTTP
QA Contact: pmac → core.networking.http
Assignee | ||
Comment 7•20 years ago
|
||
Ok, I have a fix for this. We just need to ensure we only switch the skin in the profile callback.
Assignee: darin → nobody
Component: Networking: HTTP → RDF
QA Contact: core.networking.http → core.rdf
Assignee | ||
Comment 8•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Assignee: nobody → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Assignee | ||
Updated•20 years ago
|
Attachment #154456 -
Flags: review?(bsmedberg)
Comment 9•20 years ago
|
||
you should remove the two printfs before checking in
Updated•20 years ago
|
Attachment #154456 -
Flags: review?(bsmedberg) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #154456 -
Flags: superreview?(bryner)
Assignee | ||
Updated•20 years ago
|
Attachment #154456 -
Flags: superreview?(bryner) → superreview?(dveditz)
Assignee | ||
Updated•19 years ago
|
Attachment #154456 -
Flags: superreview?(dveditz) → superreview?(darin)
Comment 10•19 years ago
|
||
Comment on attachment 154456 [details] [diff] [review] Proposed patch sorry to neglect this review.... got burried in a big queue :( sr=darin (remember to remove those printfs!)
Attachment #154456 -
Flags: superreview?(darin) → superreview+
Assignee | ||
Comment 11•19 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•