214949 - XUL error pages have no content except for Try Again link

Status: VERIFIED FIXED

(Core :: Security: CAPS, defect)

Description

[Bill Mason]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Mozilla Firebird/0.6

The XUL error pages show no text except for the Try Again hyperlink.

The Mozilla nightlies from the apparent regression timeframe are no longer on
the server, but testing with Firebird nightlies I found that:

2003072308, the pages worked
2003072408, the browser would show no error page at all
2003072607, the pages showed with only the Try Again link

Reproducible: Always

Steps to Reproduce:
1. Visit an invalid URL with browser.xul.error_pages.enabled set to true.
Actual Results:  
The XUL error page shows only the Try Again link.

Expected Results:  
The XUL error page should have rendered with its full content visible.

Comment 1

[Bill Mason]

Added kw regression, corrected Version field.

Comment 2

[Hanspeter Niederstrasser]

This also happens on Mac OS X from about the same time frame.
Hardware/OS -> All/all.

Comment 3

[Bill Mason]

Hardware/OS -> All/All per comment 2.

Comment 4

[Jeremy M. Dolan]

the 2003072408 build the reporter mentions showing no error at all may have been
during the chrome changes. Opening a JS file (or something like that) would
immediately crash Moz. A fix was checked in the next day, perhaps this
regression is related to the initial change there, or the crash fix/correction.

Note that 'select all' grabs the text from the invisible nodes, so the
&malformedURI.longDesc; / &fileNotFound.longDesc; / etc expanders are working,
so the JS must be failing the set the right node to visible.

Comment 5

[Jeremy M. Dolan]

Christopher said he's made some progress on this. Sending his way.

Comment 6

[Jason Bassford]

Now, however, that the URL of the site you attempted to go to is *finally* being
shown in the location bar.  (Also that the Try Again *isn't* pointing to the
failed URL but to the chrome that the location bar *used* to use - it's as if
the links just switched positions.)

Personally, I prefer the current behaviour to what we had before.  If "fixing"
this means reverting back to the old chrome-in-the-location-bar behaviour - then
I say don't.

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

So the problem is that whenever we hit the xul error page, a new document is
created with a chrome: URI.  The page then uses JS which triggers calls to caps
to check if it can access these properties.  At this point, we have nothing
stored in mPrincipals.  So the principal lookup fails, and we try and look up a
more general principal.  This causes failures because it gets the origin of the
principal, which gets scheme+host+port which will be in this case "chrome://global".

The fix here is two-fold:
1. Do not try to look up principals if mPrincipals.Count() is 0
2. Temporarily special case chrome principals in GetOrigin() to return the full
spec.

Note that 1. was the past behavior implicitly.  Before I changed mPrincipals to
a direct member of the class rather than a pointer to a hashtable, this code was
wrapped around |if (mPrincipals)| which also ensured that the hash was empty.

The real fix here is to have chrome: principals be the system principal, but I
would rather do that separately, as part of bug 160042.

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

Note that 2 is needed because this would have been a problem even in past builds
if there were items in mPrincipals (mPrincipals is used to remember scripts
which have been granted escalated priveleges via
netscape.security.enablePrivelege() or whatever the syntax is).

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Fix (diff -w)

As described above.

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 129337 [details] [diff] [review]
Fix (diff -w)

I'm just attaching a diff -w since it should be enough for reviewing this
patch.	Let me know if you want a normal diff as well.

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 129337 [details] [diff] [review]
Fix (diff -w)

r+sr=jst

Comment 12

[Peter Van der Beken [:peterv]]

This probably fixes bug 193033 I think. Maybe we should go for bz's suggestion
of cloning and nulling out members though?

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 129337 [details] [diff] [review]
Fix (diff -w)

Approved for 1.5b.  You might want to ping bugs 193033(?) and 160042 after this
is in.

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

Peter, I guess we could, but I'm not so sure that is the best solution...  I
think we should first try for the solution offered by bug 160042 and then see if
we can get rid of the hardcoding of how we handle different schemes in caps.

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

This was checked in to the trunk on 08/09/2003 19:26.

Comment 16

[Bill Mason]

This works so far as the page content is restored, 2003081004 PC/WinXP.

However, the "Try Again" link is pointing to the chrome: URL instead of the
failed URL that's in the URL bar.  Should this bug be reopened or a new bug
opened for that issue?

Comment 17

[Bill Mason]

My mistake, it works.  I goofed my test up.  Verifying bug fixed.

Comment 18

[Jason Bassford]

Actually, you were correct the first time.  As luck would have it my
masquerading server was down when I looked at this bug in the 8/10-04 build
under XP.  Here's what the URL of the Try Again link pointed to:

chrome://global/content/netError.xhtml?e=dnsNotFound&u=http%3A//bugzilla.mozilla.org/show_bug.cgi%3Fid%3D214949&d=bugzilla.mozilla.org%20could%20not%20be%20found.%20Please%20check%20the%20name%20and%20try%20again.#

Obviously, this is wrong.  The location bar gets it right, not the Try Again link.

Comment 19

[Jason Bassford]

Filed bug 215753 on this issue.

Comment 20

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 216180 has been marked as a duplicate of this bug. ***

Comment 21

[Jesse Ruderman]

This has regressed in today's Firebird build.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030823 Mozilla
Firebird/0.6.1+.

This bug is not present in a build from two days ago (08/21).

Comment 22

[Christopher Aillon (sabbatical, not receiving bugmail)]

So here's what's going on here:

This bug has *ALWAYS* existed if you had capability.principal.* prefs set.
The fix in bug 83536 broke it UNCONDITIONALLY.
The patch attached here fixed it unconditionally.
I backed out 83536 and subsequently this fix to get the behavior we've always had.

It probably would have been possible to leave the fix in, but backing out the
other patch was hellacious enough as it was with the massive conflicts and
munging I had to do to back it out, and I did not think about it at the time.

In summary, the behavior now is EXACTLY what was in firebird 0.6, and mozilla
1.5alpha.  It will still work for the majority of users (Jesse confirmed that he
had some capability.principal.* prefs set, which most people do not have set). I
will reland the patch in bug 83536, and subsequently the "always" fix, for this
bug when 1.6alpha is open for checkins.