161751 - Unable to change theme when capability lines are added to prefs.js

Status: RESOLVED FIXED

(Core Graveyard :: RDF, defect)

Description

[Brad Town]

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

[Michael Lefevre]

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.

Comment 2

[Brad Town]

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.

Comment 3

[jwq]

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

Comment 4

[jwq]

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

Comment 5

[[e-mail]]

Weird... this works fine for me on my Linux debug, but not on Windows...

Comment 6

[[e-mail]]

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.

Comment 7

[[e-mail]]

Ok, I have a fix for this.

We just need to ensure we only switch the skin in the profile callback.

Comment 8

[[e-mail]]

Attachment: Proposed patch

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

you should remove the two printfs before checking in

Comment 10

[Darin Fisher]

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!)

Comment 11

[[e-mail]]

Fix checked in.