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)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: brad, Assigned: neil)

Details

Attachments

(1 file)

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.
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
Weird... this works fine for me on my Linux debug, but not on Windows...
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
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
Attached patch Proposed patchSplinter Review
Assignee: nobody → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #154456 - Flags: review?(bsmedberg)
you should remove the two printfs before checking in
Attachment #154456 - Flags: review?(bsmedberg) → review+
Attachment #154456 - Flags: superreview?(bryner)
Attachment #154456 - Flags: superreview?(bryner) → superreview?(dveditz)
Attachment #154456 - Flags: superreview?(dveditz) → superreview?(darin)
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+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: