M4 AppRunner. The above URL can be opened and works fine in Nav4 or IE4. It is a stripped-down version of my cross-browser DHTML preso template that I've simplified as much as possible. On M4, the HTML elements are formatted correctly via use of the DOM's CSS support, but the index.htm document never finishes loading, and the left and right frame contents don't appear. AppRunner enters some kind of infinite loop (look at the MS-DOS window and see the messages scrolling by endlessly). It would be nice if we could fix or work around this as soon as possible because until we do, marketing can't do presentations about Gecko within AppRunner. We have to use Nav4 as the page turner and then do demos only within AppRunner.

Re-assigned to troy. The exact same problem happens in viewer so this isn't an apprunner problem. Troy, who should get this?

On 4/26/99 optimized WinNT, this crashes on Apprunner (dos box messages look redundant) but not on Viewer. Reassigning to Peter. When the crash is fixed, please reassign back to me to see why the image to the left is not showing up.

I see this too, crash on NT, infinite loop outputting this on Win98: Added page http://blues/users/ekrock/publish/bugs/M4/presohang2/index.htm to the rdf:history datasource Got a handle to forward menu item Setting forward menu item disabled Obtained MenuItem Back Setting Back menuitem to enabled Document http://blues/users/ekrock/publish/bugs/M4/presohang2/index.htm loaded successfully

With today's optimized Linux build, the document appears to be loading repeatedly in a tight infinite loop, just as in Viewer, but with the following output: nsMessengerNameSet::InitializeClasses() Initializing base classes nsComposerNameSet::InitializeClasses() Initializing base classes Alert: Alert! did not find a converter or decoderAdded page http://blues/users/ekrock/publish/bugs/M4/presohang2/index.htm to the rdf:history datasource Document http://blues/users/ekrock/publish/bugs/M4/presohang2/index.htm loaded successfully If you want the crash on NT to be a separate bug, then I think it should be filed as such, but it sure seems like this is all one big content-specific problem. The UI remains usable throughout, so I don't see what any of this has to do with XPToolkit. reassigning to rickg for triage, cc don and karnaze

Reassigning back to me.

I'm reassigning this to Nisheeth because it involves web shell and doc loader and doesn't involve frameset layout. I tried following the flow of control but got lost, since I don't know how these components play together. The same documents are getting loaded over and over again on existing web shells. The interesting data point is that it works in Viewer.

Accepting bug. I'll take a look at this today and tomorrow and update the bug report. Setting TFV to M5 for now.

I have a fix for this. I'll get it code reviewed from Kipp and give a more detailed explanation about the problem once I get to work...

OK, here's what happens. The webshell associated with index.html dispatches an onload DOM event as it processes the OnEndDocumentLoad() notificaion. The onload event triggers the onload handler for the frameset in index.html which fires a script that starts the load of title.htm (the first slide) into one of the child frames of the frameset defined in index.html. When this load finishes, OnEndDocumentLoad gets called on the child frame's webshell, and then on the top level frameset's webshell. The top level webshell processes the OnEndDocumentLoad *again* and sends another OnLoad DOM event, thus creating an infinite loop. The proposed fix is to maintain a boolean flag mProcessedEndDocumentLoad in the webshell that gets set each time an OnEndDocumentLoad() notification is processed and reset each time a new URL is loaded. Kipp, please code review the attached patch. Thanks a lot.

marking fixed

Updating QA Contact

Eric -- the file is no longer there -- can you give this a whirl and see if it is fixed? thanks

page loads fine, even get the generated CRC value for the page, marking verified