Version: Apprunner Build: March 10th Platforms: All Expected Results: The ea site should load. What I got: A crash occured when loading the page. Steps to reproduce: 1) Launch Apprunner and go to http://www.ea.com. 2) The page begins to load then crashs.

Putting on M3 radar.

Re-assigned to vidur@netscape.com and changed component to DOM Level 0. Vidur, I believe this particular page may be dying during layout of the frame http://www.ea.com/leftnav.html 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.

petersen, setting you to QA Contact since our DOM Level 0 tester has not started yet.

This is still crashing on all platforms with Mar15 build.

Additional info...Apprunner AND Viewer both crash.

This has nothing to do with JavaScript. The crash is occuring in nsObjectFrame::Reflow and is related to the OBJECT tag in the frame main.html. The OBJECT tag has a CLASSID specified. In Nav4.x we don't process the OBJECT tag and, instead, look at the alternate content (which is an EMBED tag). In Gecko, we're processing the OBJECT tag, attempting to resolve the CLASSID, failing and not dealing with the failure case. This should be dealt with by Alex and/or Andrei.

I have a fix for this. This is a dup 3075. *** This bug has been marked as a duplicate of 3075 ***

The EA site seems to be down on 3/19. I will check it later.

This bug is a duplication of 3075.

With the March 22nd Build (Mac and Windows) , the crash still occurs when attempting to open this site in the browser.

In the March 23rd Builds, Mac and Windows NT loads the page without crashing. However ,under Windows 95 and 98 , Apprunner loads a portion of the site and freezes.

Fixed in March 25th Build.

Re-opening. Crashes 4.26.99 Mac OS & Win32 build upon page load. (but works fine on Linux build.)

For some reason, two nsObjectFrames are being created for the same tag. I'm guessing that it's a problem with the alternative content handling, so I'm reassigning this to Andrei so he can take a look.

Thanks!

The big problem is I do not see crash. Continuing trying to reproduce.

<Alex, I'll check on today's builds and let you know ASAP.>

Hi, Alex --- I'm seeing this on today's Win32 build about 75% of the time on the first launch of www.ea.com. * In two other cases, I've been able to invoke the crash by placing the focus on the URL text field and pressing the return key to reload 7-8 times until a crash takes place. * In one other case, the crash didn't occur no matter how many times the page was reloaded (gave up after about 15 reloads). Hope this helps.

Moving to M6 since cannot repro this currently

Stripped down test case can be found on http://smerinthus/publish_html/Test/testea.html and is noe reproducable on my machine. I think the problem is with JavaScript. Not only tries it to create two object frames, but frame construction code is called as if there are two object tags.

Thanks to Vidur for helping me with this one. OK, looks like the problem is in css linkage, the first line in the source. Currently it is done the way when the page is completly reconstructed after style gets loaded. Hence two invokation of the frame construction code via object tag. The situation when we cannot render the object and need to get to the object tag content instead is implemented asynchroniously with CantRenderReplaceElementEvent. So when this event comes for the first time, it is often the case that we already redone the object frame and the first version of it for which this event is intended is already destroyed. Crash. Possible fixes may involve making this notification synchronious or using reference counted content in place of frame when we create the event. I need broader discussion so adding vidur and kipp.

I talked to Kipp about the fix involving holding a reference to content in the event (as opposed to a pointer to the frame). I believe he's OK with it.

[corrected title]

I checked the fix in. Please give it a try.

since Alex has a fix checked in, I'm marking bug as resolved / fix so it gets on the verify radar

With the 5/17 Builds (Mac, Win and Linux), The web site loads with out crashing.

reopening instead of writing a new bug since www.ea.com is consistently crashing on win98 build 1999071417 and linux build 1999071416. mac build is ok. Here is my stack trace from the talk back report: Trigger Type: Program Crash Trigger Reason: Illegal instruction Call Stack: (Signature = 0x00000017 995300a5) 0x00000017 StyleSetImpl::CantRenderReplacedElement [d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp, line 885] PresShell::HandleCantRenderReplacedElementEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1400] HandlePLEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1419] PL_HandleEvent [plevent.c, line 494] PL_ProcessPendingEvents [plevent.c, line 455] _md_EventReceiverProc [plevent.c, line 916] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00638c16

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

builds 1999072108 on Mac, Linux build 1999072111 on Win (95 and NT) not crashing verified