74146 - XUL pages with incorrect mimetype cause infinite windows

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Dan Rosen]

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!

Comment 1

[Blake Ross]

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

Comment 2

[gordon]

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.

Comment 3

[Gervase Markham [:gerv]]

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

Comment 4

[Braden]

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

Comment 5

[Gervase Markham [:gerv]]

"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

Comment 6

[Dan Rosen]

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...

Comment 7

[John Morrison]

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

Comment 8

[Gervase Markham [:gerv]]

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

Comment 9

[Peter Toneby]

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.

Comment 10

[Bradley Baetz]

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

Comment 11

[Brendan Eich [:brendan]]

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

/be

Comment 12

[gordon]

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.

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 14

[Gervase Markham [:gerv]]

Attachment: testcase

Comment 15

[Gervase Markham [:gerv]]

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

Comment 16

[David Hyatt]

smells ok to me.

Comment 17

[benc]

-> 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.