Closed Bug 66027 Opened 24 years ago Closed 24 years ago

Combination of closing window and submitting form crashes Mozilla

Categories

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

x86
All
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: david, Assigned: pollmann)

Details

(Keywords: crash)

my build id is 2001011906. Linux RedHat 7.0. Here is my recipe for disaster (complete mozilla crash). Create two files. the first is crashme.html containing: -------cut-------- <html><head><SCRIPT LANGUAGE="Javascript"> var popupWindow = window.open("other.html", "popup"); name="MAIN_WINDOW"; </SCRIPT></head><body onUnload="popupWindow.close();"></body></html> -------cut-------- and other.html containing: -------cut-------- <html><body><form target="MAIN_WINDOW" ACTION="crashme.html"> <INPUT TYPE="submit"> </form></body></html> -------cut--------- Open the crashme.html (using file:// or whatever...). As it opens, it opens another window, with a form submit button. Click the button and poof! Gone. The form in the popup window has a 'TARGET=' of the main window. The main window closes the popup 'onUnload' in the BODY tag.
Crashes as reported in bug. Mozilla 2001011820 on Windows 2000 SP1. Adding keyword crash.
Keywords: crash
Marking NEW as per JLP's comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing OS from "Linux" to "All". Here is a WinNT stack trace: nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x0516aad4, nsIRequest * 0x052b0770, int 65540, unsigned int 0) line 1285 + 19 bytes nsDocLoaderImpl::OnProgress(nsDocLoaderImpl * const 0x0516aad0, nsIChannel * 0x052b0770, nsISupports * 0x00000000, unsigned int 188, unsigned int 188) line 1116 nsFileChannel::OnProgress(nsFileChannel * const 0x052b077c, nsIChannel * 0x052b1320, nsISupports * 0x00000000, unsigned int 188, unsigned int 188) line 735 + 45 bytes XPTC_InvokeByIndex(nsISupports * 0x052b077c, unsigned int 3, unsigned int 4, nsXPTCVariant * 0x052595a0) line 139 EventHandler(PLEvent * 0x05272e80) line 513 + 41 bytes PL_HandleEvent(PLEvent * 0x05272e80) line 576 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ac21f0) line 509 + 9 bytes _md_EventReceiverProc(HWND__ * 0x018f028c, unsigned int 49429, unsigned int 0, long 11280880) line 1054 + 9 bytes USER32! 77e71820() 00ac21f0() No JS Engine issues apparent in stack trace, but not sure whom this bug should go to. Reassigning to Form Submission for further triage -
Assignee: rogerl → rods
Component: Javascript Engine → Form Submission
OS: Linux → All
QA Contact: pschwartau → vladimire
Summary: combination of closing window and submitting form crashes mozilla → Combination of closing window and submitting form crashes Mozilla
reassigning
Assignee: rods → pollmann
I'm a little confused here. In the testcase above: -------cut-------- <html><head><SCRIPT LANGUAGE="Javascript"> var popupWindow = window.open("other.html", "popup"); name="MAIN_WINDOW"; </SCRIPT></head><body onUnload="popupWindow.close();"></body></html> -------cut-------- and other.html containing: -------cut-------- <html><body><form target="MAIN_WINDOW" ACTION="crashme.html"> <INPUT TYPE="submit"> </form></body></html> -------cut--------- How can the attribute target="MAIN_WINDOW" be resolved, when nothing has been named "MAIN_WINDOW"? Notice the only other reference to this string was name="MAIN_WINDOW"; but this was NOT included in the window.open(). It was just an assignment to a variable. Was this a deliberate mistake? Or am I missing something here? Is "MAIN_WINDOW" a keyword in HTML?
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Hmm, this is a twisted testcase. :) It turns out name = "MAIN_WINDOW" is equivalent to window.name="MAIN_WINDOW" because all variables are by default scoped at the window object. This changes the name of the window displaying crashme.html to "MAIN_WINDOW". When the form is submitted, three things should happen. The form submit will load crashme.html into MAIN_WINDOW, first causing onUnload to fire and the popup to close, next, second causing crashme.html to refresh in MAIN_WINDOW, and thirt (since crashme.html is loaded again) a new popup should immediately open. This should leave us with two windows instead of one! I tested on WinNT build from a few days ago and this test case works fine without crashing. I also tested a Linux build from yesterday and it didn't crash, so I'm going to mark this WORKSFORME. (Johnny was able to reproduce this in a Linux build from last week though, so it was probably an bug that was fixed between now and then...)
Verifying windows 98 build 2001-01-31-14-MTEST
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.