204068 - Error pages don't work with "capability.principal.*" preferences set

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect)

Description

[Stefan Borggraefe]

This is a little late spin off from bug 156997. That bug implemented better
looking error pages. Especially see comments 39-43 there. When some prefs
starting with capability.principal.codebase.* are set the error pages only
consist of the "Try again"-Link which doesn´t even work.

Steps to reproduce:
1. Enable error pages (user_pref("browser.xul.error_pages.enabled", true);)
2. Add the following lines to your preferences:
user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p0.id", "http://bugzilla.mozilla.org");
3. Start Mozilla Navigator.
4. Type some random string in the URL bar and press return to display the error
page for DNS errors or do something else to provoke an error page.
5. See the page with only the "Try again" link in it.

When you try the same without the both capability.principal.codebase.* lines in
your Preferences you see the normal error pages.

I don´t know what for those two lines are, so I don´t really understand what´s
going on here. Probably this bug is just a symptom of a more general issue.

Comment 1

[Jeremy M. Dolan]

Just updated to
  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030724 Mozilla
  Firebird/0.6 
today and all of a sudden error pages just say try again. This pref mentioned here
is NOT set:
  % grep capa prefs.js 
  user_pref("mail.server.server1.capability", 545);
Also today going to a domain that doesn't exist (sdfgsf.com) crashes mozilla, so
it may be related to that. I filed bug Bug 213757 on the crash.

Comment 2

[Jeremy M. Dolan]

OK, I was in the wrong profile directory, but still, no .principal.codebase
stuff is set:

 % grep capabil *
 grep: lock: No such file or directory
 user.js://user_pref("capability.policy.default.Window.onunload", "noAccess");
 user.js://user_pref("capability.policy.default.Window.title.set", "noAccess");

And those have been set for ages, nothing new there.

Comment 3

[Jesse Ruderman]

Caillon explained what's going on in bug 214949 comment 22.  Depends on bug
83536, which caillon will probably re-fix in 1.6 alpha.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Thanks for finding this for me Jesse.  Accepting bug.  Note that this is an
issue for capability.principal.* in general, not specifically for codebase
principals.

Comment 5

[Jeremy M. Dolan]

Fixing really annoying quote char. that confuses my mailer. Sorry for spam.

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

This should be fixed with the re-landing of bug 83536.