193033 - Errors in script security manager for chrome XHTML

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Adam Lock]

Attempt to load any of the following XHTML files by typing their chrome URL
straight into the address bar of mfcembed or mozilla generates dozens of
assertions and failure of the javascript to execute.

chrome://global/content/mozilla.xhtml
chrome://global/content/netError.xhtml
chrome://global/locale/about.xhtml

It looks as though the script security manager is attempting to create a URI
from "chrome://global/" and the chrome protocol handler is choking on it. The
code that makes the chrome protocol handler canonify the URI was checked in for
182124 so I'm guessing that is where the problem first came from.

This breaks the new error pages since the javascript on the page is unable to
execute.

NTDLL! 77f767cd()
nsDebug::Assertion(const char * 0x0201bdc4, const char * 0x10135f64, const char
* 0x0201bd8c, int 0x000001c9) line 280 + 13 bytes
nsDebug::Error(const char * 0x0201bdc4, const char * 0x0201bd8c, int 0x000001c9)
line 463 + 22 bytes
SplitURL(nsIURI * 0x0120c708, nsCString & {...}, nsCString & {...}, nsCString &
{...}, int * 0x0012f27c) line 457 + 21 bytes
nsChromeRegistry::Canonify(nsChromeRegistry * const 0x010d8838, nsIURI *
0x0120c708) line 537 + 34 bytes
nsChromeProtocolHandler::NewURI(nsChromeProtocolHandler * const 0x00c32428,
const nsACString & {...}, const char * 0x00000000, nsIURI * 0x00000000, nsIURI *
* 0x0012f4e8) line 607 + 32 bytes
nsIOService::NewURI(nsIOService * const 0x00c10230, const nsACString & {...},
const char * 0x00000000, nsIURI * 0x00000000, nsIURI * * 0x0012f4e8) line 405 +
39 bytes
NS_NewURI(nsIURI * * 0x0012f4e8, const nsACString & {...}, const char *
0x00000000, nsIURI * 0x00000000, nsIIOService * 0x00c10230) line 106 + 28 bytes
nsScriptSecurityManager::GetCodebasePrincipal(nsScriptSecurityManager * const
0x010f8718, nsIURI * 0x011933f8, nsIPrincipal * * 0x0119a058) line 1732 + 39 bytes
nsDocument::GetPrincipal(nsDocument * const 0x01199ff0, nsIPrincipal * *
0x0012f654) line 878 + 57 bytes
nsContentUtils::GetDocumentAndPrincipal(nsIDOMNode * 0x012031d4, nsIDocument * *
0x0012f658, nsIPrincipal * * 0x0012f654) line 480
nsContentUtils::CheckSameOrigin(nsIDOMNode * 0x01199ff4, nsIDOMNode *
0x012031d4) line 545 + 57 bytes
nsDocument::InsertBefore(nsDocument * const 0x01199ff4, nsIDOMNode * 0x012031d4,
nsIDOMNode * 0x00000000, nsIDOMNode * * 0x0012f710) line 3132 + 38 bytes
nsDocument::AppendChild(nsDocument * const 0x01199ff4, nsIDOMNode * 0x012031d4,
nsIDOMNode * * 0x0012f710) line 3295
nsXMLContentSink::AddContentAsLeaf(nsIContent * 0x012031b8) line 755 + 56 bytes
nsXMLContentSink::FlushText(int 0x00000001, int * 0x00000000) line 1306
nsXMLContentSink::HandleDoctypeDecl(nsXMLContentSink * const 0x011a0040, const
nsAString & {...}, const nsAString & {...}, const nsAString & {...}, const
nsAString & {...}, nsISupports * 0x00000000) line 1925
nsExpatDriver::HandleEndDoctypeDecl() line 557 + 62 bytes
Driver_HandleEndDoctypeDecl(void * 0x0120cbe0) line 166
doProlog(void * 0x0120cc78, const encoding * 0x0209d688 little2_encoding, const
char * 0x0120ad52, const char * 0x0120ba76, int 0x00000011, const char *
0x0120ad54, const char * * 0x0012fb64) line 2392 + 13 bytes
prologProcessor(void * 0x0120cc78, const char * 0x0120ac38, const char *
0x0120ba76, const char * * 0x0012fb64) line 2254 + 36 bytes
prologInitProcessor(void * 0x0120cc78, const char * 0x0120ac38, const char *
0x0120ba76, const char * * 0x0012fb64) line 2243 + 21 bytes
XML_Parse(void * 0x0120cc78, const char * 0x0120ac38, int 0x00000e3e, int
0x00000000) line 926 + 40 bytes
nsExpatDriver::ParseBuffer(const char * 0x0120ac38, unsigned int 0x00000e3e, int
0x00000000) line 775 + 24 bytes
nsExpatDriver::ConsumeToken(nsExpatDriver * const 0x0120cbe4, nsScanner & {...},
int & 0x00000000) line 884 + 32 bytes
nsParser::Tokenize(int 0x00000000) line 2543 + 26 bytes
nsParser::ResumeParse(int 0x00000001, int 0x00000000, int 0x00000001) line 1770
+ 31 bytes
nsParser::OnDataAvailable(nsParser * const 0x011feebc, nsIRequest * 0x01193fd0,
nsISupports * 0x00000000, nsIInputStream * 0x011946c4, unsigned int 0x00000000,
unsigned int 0x0000071f) line 2405 + 21 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x011937d8,
nsIRequest * 0x01193fd0, nsISupports * 0x00000000, nsIInputStream * 0x011946c4,
unsigned int 0x00000000, unsigned int 0x0000071f) line 243 + 46 bytes
nsJARChannel::OnDataAvailable(nsJARChannel * const 0x01193fd8, nsIRequest *
0x01194488, nsISupports * 0x00000000, nsIInputStream * 0x011946c4, unsigned int
0x00000000, unsigned int 0x0000071f) line 677 + 57 bytes
nsInputStreamPump::OnStateTransfer() line 402 + 65 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x0119448c,
nsIAsyncInputStream * 0x011946c4) line 317 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x01194f7c) line 112
PL_HandleEvent(PLEvent * 0x01194f7c) line 663 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00bbbfe0) line 593 + 9 bytes
_md_TimerProc(HWND__ * 0x001303c4, unsigned int 0x00000113, unsigned int
0x00000000, unsigned long 0x01f2e9dc) line 964 + 9 bytes
USER32! 77d67ad7()
USER32! 77d6cb51()
USER32! 77d4425d()
USER32! 77d44d58()
CWinThread::Run() line 487 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x00141f0c, int 0x00000001) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00141f0c,
int 0x00000001) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e814c7()

Comment 1

[Adam Lock]

This is a temporary work around that I used to make error pages work again.

Index: mozilla/rdf/chrome/src/nsChromeProtocolHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/rdf/chrome/src/nsChromeProtocolHandler.cpp,v
retrieving revision 1.97
diff -u -r1.97 nsChromeProtocolHandler.cpp
--- mozilla/rdf/chrome/src/nsChromeProtocolHandler.cpp  8 Jan 2003 22:41:47
-0000       1.97
+++ mozilla/rdf/chrome/src/nsChromeProtocolHandler.cpp  12 Feb 2003 22:36:10 -0000
@@ -604,9 +604,9 @@

     NS_ASSERTION(reg, "Must have a chrome registry by now");

-    rv = reg->Canonify(uri);
-    if (NS_FAILED(rv))
-        return rv;
+//    rv = reg->Canonify(uri);
+//    if (NS_FAILED(rv))
+//        return rv;

     *result = uri;
     NS_ADDREF(*result);

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yeah, but that change would break stylesheet loading all over and a few other
things, most likely.

The real issue is this code in nsCodebasePrincipal::GetOrigin :

157     if (NS_SUCCEEDED(mURI->GetHostPort(hostPort)))
158     {
159         nsCAutoString scheme;
160         rv = mURI->GetScheme(scheme);
161         NS_ENSURE_SUCCESS(rv, rv);
162         *origin = ToNewCString(scheme + NS_LITERAL_CSTRING("://") + hostPort);
163     }        

For the "chrome:" protocol, the "host" comes out as "global" and so we try to
create a uri for chrome://global/

There are probably other cases in which this would also produce nonsense...

The right fix would have been to make it chrome:///global/whatever to start
with, since that's what the structrure _really_ corresponds to.... but I guess
it's about 5 years too late for that.  :(

Perhaps we can change the GetOrigin() code to simply clone the URI and then set
the path and such to empty strings?  Or would that break what unclone-able
mailnews uris we have around?

Comment 3

[benc]

If bz's change landed 01-05-2003, then why does: 
chrome://navigator/content/navigator.xul

work in Mozilla 1.3b? That is what I use as an accceptance test for chrome handlers.

As for having URls that have incorrect stuff in the "hostname" field (between
slash 2 and 3)...

file: ignores most strings in between slash 2 & 3.
file: also has code that identifies some strings (like drive letters) and
"promotes" them past the 3rd slash.

resource: has similar code, I *think*, but not entirely sure about that.

So you can probably find existing code that moves around the values as you parse
the URL...

Comment 4

[Mitchell Stoltz (not reading bugmail)]

> Perhaps we can change the GetOrigin() code to simply clone the URI and then set
> the path and such to empty strings?  Or would that break what unclone-able
> mailnews uris we have around?

I think this suggestion would work fine - mailnews URLs are already
special-cased elsewhere in this function. I'm a little worried about performance
with this change, but it's worth a try. I recently changed this function to
exclude username & password, which is probably what caused this bug.

Comment 5

[Doug Turner (:dougt)]

over to mitch per bz's comment.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is no longer an issue now that chrome XHTML gets the system principal, right?