Closed Bug 30627 Opened 20 years ago Closed 20 years ago
<frameset> onload handler must fire _after
_ child documents have loaded
The following issue came up during the course of looking at bug #23777. That bug was fixed (it was a floating point error in handling "HTTP/0.9", surprisingly enough). However, this problem still remains. Using today's mozilla.org bits on win95, on *one* occasion, an alert is thrown up that said something like '... thePage has no properties ...'. [I haven't been able to reproduce this error a second time.] There is a crude testcase at http://qsilver.queensu.ca/~buslib/frameload/parent.html (Run with '-console' to see the output). Here are comments by vidur and I from bug #23777. CC: travis for webshell. ------- Additional Comments From email@example.com 2000-01-18 17:40 --- One thing that I noticed about members.xoom.com/whatever pages was that they all have this kind of structure (abbreviated): <frameset onload='doRewrite();'> <frame name='pb'> <frame name='thePage'> </frameset> Now, in 4.x and the js client docs, the onload handler for <frameset> fires *after* the two child frames have loaded (have fired onload). But in mozilla it fires without waiting for the child frames to load. In the particular case of 'members.xoom.com/whatever', doRewrite() manipulates the DOM of <frame name='thePage'>. But "thePage" hasn't loaded at the time that doRewrite() tries to rewrite it's links. This may be the trigger of the eventual crash. (At the very least, it's a bug in its own right -- I'll set up a simple test case and update this bug or file a new one.) But cc: vidur, in case this is already something he knows about. ------- Additional Comments From firstname.lastname@example.org 2000-01-19 16:59 --- Well...the described bug could well be considered a webshell issue, but I'll hold onto it. Currently onload handlers are firing from notifications that end up in the webshell. The notification for the frameset probably happens when the frameset document itself completes loading. This doesn't match DOM expectations, which might mean we need to store additional state.
One note about the above -- I refer to crash in my comments of jan 18. However, that does not apply, as far as I know, to this bug report. It does not crash.
Currently the onload handler for a page fires in nsWebShell::OnEndDocumentLoad, when the parser is done with the page. We probably need to get notification when child webshells load and fire the onload only when the number of notifications equals the number of children we have.
Status: NEW → ASSIGNED
Target Milestone: M16
Nominating nsbeta2. We have to start drawing a line on DOM0 backward compatibility; these bugs are supposed to be a high priority for nsbeta2 per the beta2 criteria.
This is also what the behaviour of xul:iframe's should be (and is not at this time): the parent onload handler must fire after the child iframe's have fired their onload. The xul iframes should pick up this change when it's done in dom, but need to check that this is so (i.e., xul does not need any further changes to make this work).
Per chofmsnn all user pages on xoom.com are busted. if this is webshell lets get valeski/adam lock kicking some butt on it. Putting on [nsbeta2+] radar for beta2 fix.
Adding jst to the list since I know he had a fix for this...
The pages load ok for me, but what is broken is the the frameset is trying to rewrite all the <A HREF> in the lower frame -- since this code executes before the lower frame has loaded, this throws a bunch of js exceptions, and the rewrites fail (thus breaking the xoom.com navigation 'scheme')
Adam, I can't say I have a fix, but I have a "hack" in my tree that fixes this, but there's still a lot to be done before it's ready to be checked in. What I did so far was to add a "state" getter to nsIDocShellTreeItem and based on that the docshell root checks its children when one of them is done loading, and if all child docshells are done, it fires the onload handlers. Two problems still remain: 1. there's no clean way for a docshell child to tell its parent that it's done loading. 2. There's no way for a docshell parent to cleanly fire the onload event, it's possible to fire the event from a parent, but the child doesn't know about the event being fired and it needs to know this to prevent futher fireing of the onload handler if a sibling docshell is reloaded. Here's what I propose doing to continue cleaning this up: Make the tree item state read/write, the different states should be something like this: stateNotLoadingYet stateLoading stateLoaded stateDone (please suggest better names) and then we make the onload event fire when the state is changed from stateLoaded to stateDone. We also need to add a method to nsIDocShell that lets a child inform it's parent (or root, actually) that the childs state changed, something like this: [noscript] childStateChanged(in nsIDocShellTreeItem child, long oldState); I think we'd be able to cover all possible scenarios with something close to the above suggestion, the possible cases we need to handle properly is: a. Loading a standalone document. b. Loading a frameset document with one or more frames in it, possibly even nesetd frames of course. c. Loading a new document into one frame in a frameset (ie if a link is clicked in the frame), ie the frameset itself doesn't reload, nor the other frames. (Cc:ing rpotts since I think he's working on related things in the docshell.) Adam (and others), does this sound reasonable?
Adding rpotts to the cc: list to get his input.
Taking this bug off Vidurs list.
Assignee: vidur → jst
Status: ASSIGNED → NEW
Adam, I spoke to Johnny about this and he feels that this bug should belong to the docshell owners. He's away for the DOM face to face meeting in Germany, so I'm doing the re-assignment for him.
Assignee: jst → adamlock
Rick - what effects do your recent changes to nsIWebProgressListener have on this problem?
M16 has been out for a while now, these bugs target milestones need to be updated.
Assignee: adamlock → rpotts
*** Bug 45369 has been marked as a duplicate of this bug. ***
-> jst Johnny has agreed to look at my onLoad/onUnload bugs while I'm gone...
Assignee: rpotts → jst
Status: NEW → ASSIGNED
OS: Windows 95 → All
Priority: P3 → P2
Hardware: PC → All
Whiteboard: [nsbeta2+] → [nsbeta2+][ETA 7/25]
Target Milestone: M16 → M18
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I don't know what fixed this nor when that happened, but I'm unable to reproduce this now, it used to be trivial to reproduce, but now it's much less so... Marking WORKSFORME.
Yeah, this is doing the right ordering now (even with multiple nested framesets (win32/linux)).
marking verified worksforme with the 2000080404 binaries on win2k/linux/mac. Prashant, there are some testcases for this here: A simple two-frame frameset (dumps to console) http://jrgm.mcom.com/testcase/dom/frames/frameset-onload/001/ A nested two-frameset/two-frames-per-frameset (dumps to console) http://jrgm.mcom.com/testcase/dom/frames/frameset-onload/002/ A nested two-frameset/two-frames-per-frameset (throws up alerts) suitable for testing the Mac or Nav4.x http://jrgm.mcom.com/testcase/dom/frames/frameset-onload/003/
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.