multi-frame doc with JavaScript enters infinite loop (doc loading) on open

VERIFIED FIXED in M5

Status

()

Core
Layout: HTML Frames
P1
critical
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: ekrock's old account (dead), Assigned: Nisheeth Ranjan)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix in hand. awaiting checkin..., URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: don → troy
Component: Apprunner → Layout

Comment 1

19 years ago
Re-assigned to troy.

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

Updated

19 years ago
Assignee: troy → karnaze
Component: Layout → HTMLFrames

Updated

19 years ago
Assignee: karnaze → trudelle
Severity: normal → critical

Comment 2

19 years ago
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.

Updated

19 years ago
Summary: multi-frame doc with JavaScript enters infinite loop (doc loading) on open → multi-frame doc with JavaScript enters inf`inite loop (doc loading) on open

Comment 3

19 years ago
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

Comment 4

19 years ago
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
Assignee: trudelle → rickg
Summary: multi-frame doc with JavaScript enters inf`inite loop (doc loading) on open → multi-frame doc with JavaScript enters infinite loop (doc loading) on open

Updated

19 years ago
Assignee: rickg → karnaze

Comment 5

19 years ago
Reassigning back to me.

Updated

19 years ago
Assignee: karnaze → nisheeth
Priority: P3 → P1

Comment 6

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M5
(Assignee)

Comment 7

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

Updated

19 years ago
Whiteboard: investigating
(Assignee)

Updated

19 years ago
Whiteboard: investigating → fix in hand. awaiting code review.
(Assignee)

Comment 8

19 years ago
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...
(Assignee)

Comment 9

19 years ago
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.
(Assignee)

Comment 10

19 years ago
Created attachment 116 [details] [diff] [review]
Patch to fix this bug

Updated

19 years ago
Whiteboard: fix in hand. awaiting code review. → fix in hand. awaiting checkin...

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 11

19 years ago
marking fixed

Updated

19 years ago
QA Contact: 3853 → 3849

Comment 12

19 years ago
Updating QA Contact

Comment 13

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

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 14

19 years ago
page loads fine, even get the generated CRC value for the page, marking verified
You need to log in before you can comment on or make changes to this bug.