Open Bug 13701 Opened 21 years ago Updated 2 years ago

DOM is destroyed while onunload is still executing


(Core :: DOM: Core & HTML, defect, P5)






(Reporter: jdunn, Unassigned)




(Keywords: dom0, testcase)


(1 file)

This was reported on 4.x and can not be fixed on that codebase.

A brief description of the symptom(s):
The javascript unload handler of a page is terminating half way through its
execution.  The <document> object is not valid during the unload of a page even
though the script on that page is in the process of executing.

A brief summary of the problem(s):
The problem is that the DOM is being erased before the onUnload processing has
been completed.  The DOM needs to be released after the onUnload processing has
been completed.  This is an enterprise critical problem.  We rely on this
onUnload event to save any persistable data on the page.

A step by step testcase: (ref. test case files in above URL)

1.) From the file system, open the page <NetscapeFrameSet.html>.  This page
contains a frameset consisting of several frames.  The frames TaskBar,
TaskBarLogo, and PermanentFrame are just place holders.  The test case is in
the ApplicationArea frame.  The ApplicationArea frame contains a body tag with a
java script function named swapSave(). swapSave() is called on the onUnload
event of the body.  The page also contains a form with several text form
elements.  The swapSave function enumerates through all of the form elements on
the page and prints them out to a debug window.

2.) After the page has been loaded, navigate to a page other than
NetscapeFrameSet i.e. <> and then return to NetscapeFrameSet.
You will notice that in the debug window, the enumeration of the form elements
in the swapSave function never completes.  The function stops when making a
reference to the document object.
Assignee: karnaze → pollmann
Eric, please determine if this is yours or Vidur's.
Closed: 21 years ago
Component: HTMLFrames → DOM Level 0
OS: Windows NT → All
Hardware: PC → All
Resolution: --- → WONTFIX
This is not an exact quote, but from what Vidur said, it sounds like:

"Since this didn't work in communicator, we're not going to try to make it work
in Gecko."

I'm marking this WONTFIX.  If you absolutely need it fixed, please reopen.
reopened after talking to vidur.  Here is the original 4.x bug.

If you just open ApplicationArea.html the correct behavior
occurs, it only fails when it is in a frameset.
Clearing WON'T FIX resolution due to reopen.

Please give this bug a Target Milestone.  Thanks!
Resolution: WONTFIX → ---
Target Milestone: M15
This isn't marked blocker so I won't likely get to it before beta.  Marking M15.
QA Contact: beppe → desale
After careful consideration, I've decided that I probably won't get this bug in
for M12.  Currently I have nearly 50 bugs scheduled for M13, so there is a
possibility that this bug may need to be moved out farther still.
Target Milestone: M13 → M17
Marking M17. Rare case and even though it didn't work in 4.x, we survived. ;->
Target Milestone: M17 → M21
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: M21 → Future
Keywords: dom0
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Reassigning to general@dom.bugs to get a decision on this "bug". Also changing
summary and attaching a testcase.
Summary: while executing the onunload event handler, the DOM is being destroyed.
This means that code like document.getElementById("body") doesn't work in the
onunload handler. Strangely however document.body still works.

No idea whether this is fixable.
Assignee: alexsavulov → general
Keywords: testcase
QA Contact: desale → ian
Summary: Communicator-Java unload handler hangs → DOM is destroyed while onunload is still executing
document.body is cached on the document object...

Is this still an issue now that we have an onbeforeunload event?  I can't find
any information that speaks to when exactly onunload is fired...

Code in onbeforeunload can never know if the window will actually be closed or
not.  In order to confirm with the user, you have to *return* something.  Any
cleanup can't happen until closing the window really is confirmed, i.e. when
onunload fires.  The two events are both important for web apps.
Assignee: general → nobody
QA Contact: ian → general
Whiteboard: [needs status update]
Flags: wanted1.9.2?
Whiteboard: [needs status update]
Flags: wanted1.9.2?
Bulk priority change, per :mdaly
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.