Since the abrupt and unannounced checkin of the fix for bug 28237, XUL pages served remotely (such as scc's sidebar panels, or some testcases on mozilla.org) with the old, invalid XUL mimetype of text/xul cause infinite windows to come up. For example: load the first testcase under Debug -> XBL Demos (#0, remote XBL) in any build after 25 Mar. Expected results: pop up unknown content-type handler dialog. Actual results: have fun trying to close all the blank new windows as they pop up!

Abrubt and unannounced! That bug's been a long time coming, around since February of last year! Anyways, I just checked it in when I was asked to. Don't shoot the messenger, and all that... (cc'ing the person you _should_ be shootig ;-)

It's not clear to me from the description so far why this is a network:cache bug. Vanna, I'd like to buy a clue please.

Yep, shoot me if you must. In the mean time, let's work out how to fix this. It's a webserver configuration issue, right? It's nothing to do with the files. So, I'll send mail to endico and scc to tell them about it. Any other webservers you know serving text/xul, tell them too. I thought there would have been some announcement about this... maybe that was my job. <sigh> This bug, meanwhile, can morph into "why do we get infinite blank windows?" :-) Gerv

Gerv: The browser should not get totally jiggy if a server sends the wrong content type for XUL. The simplest explanation (without doing any actual investigation) is that there are one or more places in the code that don't know how to handle unrecognizable data when it's expecting to get XUL. It seems reasonable to suspect that the same behavior would have occured before (bug 28237 was fixed) if the browser was sent a type other than "text/xul" for XUL data. (For the record, I would have expected that patch to see wider review by the XUL folks before being applied... water under the bridge, now; but I don't think it's fair to blame Gerv for the seeming abruptness of the patch application. OTOH, given the history of bug 28237, I'm not inclined to blame a non-Netscape developer with checkin privileges for deciding that the bug had remained open long enough. Moving on...)

"Gerv: The browser should not get totally jiggy if a server sends the wrong content type for XUL." Absolutely :-) We've uncovered a bug, which can only be a good thing. Let's go fix it :-) Gerv

Okay, maybe not abrupt, but definitely unannounced <grumble grumble>... But never mind that. Hyatt suggested I assign it to cache, due to the cache landing (??). The problem is in necko somewhere, afaict (likely forgetting to delegate to the UCTH in this case). Feel free to bounce the bug around. But even if scc and mozilla.org forget to update their mimetype for a while, we shouldn't be seeing this infinite window problem, only an unknown mimetype dialog...

Here's the stack. I think things start going awry in nsURILoader::DispatchContent, where it does this // no registered content listeners to handle this type!!! so go to the // register and get a registered nsIContentHandler for our content type. // Hand it off to them... // eventually we want to hit up the category manager so we can allow // people to over ride the default content type handlers....for now... // i'm skipping that part. nsCAutoString handlerContractID (NS_CONTENT_HANDLER_CONTRACTID_PREFIX); handlerContractID += aContentType; nsCOMPtr<nsIContentHandler> aContentHandler; rv = nsComponentManager::CreateInstance(handlerContractID, nsnull, NS_GET_IID(nsIContentHandler), getter_AddRefs(aContentHandler)); if (NS_SUCCEEDED(rv)) // we did indeed have a content handler for this type!! yippee... { rv = aContentHandler->HandleContent(aContentType, "view", aWindowTarget, aSrcWindowContext, request); *aAbortProcess = PR_TRUE; } return rv; } ... and so, the component manager succeeds in the createinstance for "@mozilla.org/uriloader/content-handler;1?type=text/xul", and it's off to the races. bonsai is sick right now, but I'm guessing mscott knows who owns this code (if not him). Can we just put a bandaid patch in for now, and not hose people over 'text/xul'. nsXULWindow::CreateNewContentWindow(nsXULWindow * const 0x00000001, int 15763464, nsIDocShellTreeItem * * 0x0012f5e8) line 1253 nsXULWindow::GetNewWindow(nsXULWindow * const 0x044b57a0, int 4094, nsIDocShellTreeItem * * 0x0012f5e8) line 1145 nsContentTreeOwner::GetNewWindow(nsContentTreeOwner * const 0x04618278, int 4094, nsIDocShellTreeItem * * 0x0012f5e8) line 210 nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x00b09014, nsIDOMWindow * 0x0462aa94, const char * 0x0452a7a4, const char * 0x00000ffe, const char * 0x04618280, int 0, unsigned int 0, long * 0x04ba0bd4, nsIDOMWindow * * 0x0012f8ac) line 494 GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x0462aa90, JSContext * 0x040965f0, long * 0x04ba0bc8, unsigned int 2, int 0, nsIDOMWindowInternal * * 0x0012f9b8) line 3011 + 65 bytes GlobalWindowImpl::Open(GlobalWindowImpl * const 0x0462aa94, JSContext * 0x040965f0, long * 0x04ba0bc8, unsigned int 2, nsIDOMWindowInternal * * 0x0012f9b8) line 2083 nsBrowserContentHandler::HandleContent(nsBrowserContentHandler * const 0x04b76310, const char * 0x0452d638, const char * 0x0194bbd8 `string', const char * 0x1003c600 gCommonEmptyBuffer, nsISupports * 0x0452a4b0, nsIRequest * 0x04685a58) line 1528 nsURILoader::DispatchContent(nsURILoader * const 0x046545ec, const char * 0x0452d638, int 0, const char * 0x1003c600 gCommonEmptyBuffer, nsIRequest * 0x04685a58, nsISupports * 0x00000000, nsIURIContentListener * 0x00000004, nsISupports * 0x04626758, char * * 0x0012fb30, nsIURIContentListener * * 0x0012fb60, int * 0x0012fb28) line 1077 + 24 bytes nsDocumentOpenInfo::DispatchContent(nsDocumentOpenInfo * const 0x0012f488, nsIRequest * 0x04685a58, nsISupports * 0x00000000) line 318 nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x04653598, nsIRequest * 0x04685a58, nsISupports * 0x00000000) line 241 + 11 bytes nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x046535d8, nsIRequest * 0x04685a58, nsISupports * 0x00000000) line 1095 + 21 bytes nsStreamListenerTee::OnStartRequest(nsStreamListenerTee * const 0x04b86838, nsIRequest * 0x04685a58, nsISupports * 0x00000000) line 13 nsHTTPServerListener::FinishedResponseHeaders(nsHTTPServerListener * const 0x0012f488) line 1027 + 14 bytes nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x045188ec, nsIRequest * 0x04b8ac60, nsISupports * 0x04685a58, nsIInputStream * 0x045188ec, unsigned int 0, unsigned int 399) line 419 nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03f1c050) line 161 + 30 bytes nsStreamObserverEvent::HandlePLEvent(PLEvent * 0x04b899fc) line 79 PL_HandleEvent(PLEvent * 0x04b899fc) line 589 PL_ProcessPendingEvents(PLEventQueue * 0x1002a737) line 518 + 6 bytes _md_EventReceiverProc(HWND__ * 0x00c04300, unsigned int 4200155, unsigned int 3652512, long 0) line 1069 + 10 bytes nsAppShellService::Run(nsAppShellService * const 0x0037bba0) line 408 main1(int 1, char * * 0x00373fd8, nsISupports * 0x00372758) line 1021 + 9 bytes main(int 1, char * * 0x00373fd8) line 1316 + 25 bytes WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00400000, char * 0x00132c81, HINSTANCE__ * 0x00400000) line 1334 + 21 bytes MOZILLA! WinMainCRTStartup + 308 bytes

Hmm. The MIME type has now been fixed on http://www.mozilla.org but when trying the XBL Demo #0 I get an "unknown content type" dialog. The unknown content type is application/vnd.mozilla.xul+xml. This is somewhat worrisome... Gerv

I have had my webserver wrongly setup (sending text/xul instead of application/vnd.mozilla.xul+xml) but mozilla was complaining about not knowing anything about how to handle application/vnd.mozilla.xul+xml when my webserver did in fact send text/xul. Now I have fixed so the server send application/vnd... and mozilla is still complaining about not knowing how to handle it. I think it would be appropriate to have it complain about text/xul as a wrong mime-type, and not convert it into application/vnd... which imho is very wrong.

The "moz-displays-the-wrong-mimetype" bug is 74510.

Why is this on gordon's list? law, mscott: any thoughts? /be

hyatt, do you know if this is still happening? This bug is just languishing in my queue. Don't feel you need to keep it, just because I assigned it to you. Share the love.

See also the bug I filed a while back, bug 74616.

OK, I attached the above as text/xul and I get a Unknown Content Type dialog for text/xul. 2001-04-17. Seems good to me... Gerv

smells ok to me.

-> Networking qa to me. VERIFIED: Mozilla 0.9 all plats. clicked on test case and got: "Downloading This file has mime type text/xul and cannot be viewed using Mozilla. You can open it with another application, or save it to disk." I'm not going to test past this dialog at this point unless someone wants me to.