build: ftp://ftp.mozilla.org/pub/mozilla/nightly/99-03-09/mozilla-win32.zip . . . . . . . . Mar 09 11:34 2511k runtime: ix86 Microsoft Windows 95 4.00.950 B IE 4.0 4.72.2106.8 mermaid computer NEPTUN Pentium(r) 32.0 M RAM S3 Trio64V2(DX/GX) 4.10.00.1555, 4.10.1555 once it crash and once apprunner freezes mozilla. Crash.. APPRUNNER caused invalid pageerror in module RAPTORHTML.DLL at address 022f:00fd3fd8. Content of registers: EAX=00000000 CS=022f EIP=00fd3fd8 EFLGS=00010246 EBX=00a24974 SS=0237 ESP=0076b4b4 EBP=0076b674 ECX=0076b658 DS=0237 ESI=00a249c0 FS=0e47 EDX=0076b4b0 ES=0237 EDI=00000000 GS=0000 Byte at CS:EIP: 8b 08 57 8d 55 a8 57 52 ff 75 e4 50 ff 51 10 8b Stack content: 00000000 00000000 00000000 00a24970 0076b95c 0076b81c 00fd9d59 00a24870 0076b900 0076b81c 00000020 00000000 00000000 00000000 00000000 00000000 SelectCutCopyPaste from apprunner.exe: Adding menu listener to [Personal Bookmarks] nsMessengerNameSet::AddNameSet() Registering Messenger in the JS nsMessengerNameSet::InitializeClasses() Initializing base classes nsMessengerNameSet::AddNameSet() Registering Messenger in the JS nsMessengerNameSet::InitializeClasses() Initializing base classes nsMessengerNameSet::InitializeClasses() Initializing base classes Going Back Browser disabling buttons Goto 1 Browser enabling buttons nsMessengerNameSet::InitializeClasses() Initializing base classes debug reset selection has been called debug reset selection has been called debug reset selection has been called nsMessengerNameSet::InitializeClasses() Initializing base classes

Re-assigned to matt@netscape.com and re-wrote summary. Matt, can you find out who should really get this bug? I reproduced the crash just going to the page. Looking at the source (with 4.x :-) it looks like some Javascript is trying to access the navigator object. Is this just missing functionality that joki or someone on the DOM team needs to implement? Or should we implement it? Of course, it shouldn't crash either ...

Putting on M3 radar.

Re-assigned to vidur@netscape.com and component to DOM Level 0. Vidur, I believe this particular page may be dying in some Javascript which access the navigator component. I don't think we have to implement the navigator component for M3, but we shouldn't crash. BTW, there are a few other bugs out there like this.

This is crashing in the view also so it is probably vidur's bug in nsObjectFrame.cpp PRInt32 x = NSTwipsToIntPixels(origin.x, t2p); PRInt32 y = NSTwipsToIntPixels(origin.y, t2p); PRInt32 width = NSTwipsToIntPixels(aMetrics.width, t2p); PRInt32 height = NSTwipsToIntPixels(aMetrics.height, t2p); nsRect r = nsRect(x, y, width, height); static NS_DEFINE_IID(kIWidgetIID, NS_IWIDGET_IID); nsresult rv = nsRepository::CreateInstance(aWidgetCID, nsnull, kIWidgetIID, (void**)&mWidget); // XXX use rv! nsIWidget *parent; parentWithView->GetOffsetFromWidget(nsnull, nsnull, parent); mWidget->Create(parent, r, nsnull, nsnull); // See if the widget implements the CONTENT CONNECTOR interface. If it // does, we can hand it the content subtree for further processing. nsIContentConnector* cc; if (NS_OK == mWidget->QueryInterface(kIContentConnectorIID, (void**)&cc)) { cc->SetContentRoot(mContent); NS_IF_RELEASE(cc); } mWidget->Show(PR_TRUE); } }

Moved to M5 by rickg. beppe, set QA Contact to pdesale when he gets here please.

changing QA contact to Prashant

There doesn't seem to be a crash here anymore. Question to the bug submitter: Is the original problem you're seeing with or without the presence of the Flash plugin? I tried it without a flash plugin and I found that the page http://www.takeover.nl presents a problem. Specifically, it first checks for the presence of the Flash plugin. If that test fails (and it does on my build), it sets the window.location to a relative URL representing page that will presumably show the failure message. We process the location change and call LoadURL on the containing web shell. However, this does not terminate document processing and we process the next SCRIPT block that checks to see if Java is enabled (and it isn't) and proceeds to set the window.location to the same relative URL as the original fail case. However, since we've already set the window.location, this second relative URL is incorrectly resolved relative to the first relative URL. Either way, it seems like we need to stop document processing as soon as we see a LoadURL call. Nisheeth, what are your thoughts as WebShell owner?

>There doesn't seem to be a crash here anymore. crash problem is gone alright! >Question to the bug submitter: Is the original problem you're seeing with or >without the presence of the Flash plugin? without.

Waiting for a response from Nisheeth.

Currently, we call nsWebShell::Stop() when we load a new url. That stops the streams that are being loaded by netlib for the current document. But, I don't think that aborts processing in the parser. I think the parser needs to provide a method for aborting the processing of the current document. Then, the webshell can call that method from nsWebShell::Stop() which should fix this bug. CCing rickg and harishd, the parser gurus for input.

As of now the parser doen't have a mechanism to abort parsing in the middle of a document load. Rick and I are aware of this problem.

The parser needs to be able to deal with a return code and/or implement a method that indicates that the parsing process should stop. Reassigning to one of the current parser owners.

Vidur, the Terminate() method is in place. Use this to stop the parsing process. FYI: Call to the parser's Terminate() will also stop building content model [ in CNavDTD ] for the rest of the tokens in the Tokenizer. Marking bug fixed.

Marking verified.