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)
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.
Comment 1•24 years ago
|
||
Crashes as reported in bug.
Mozilla 2001011820 on Windows 2000 SP1.
Adding keyword crash.
Keywords: crash
Comment 2•24 years ago
|
||
Marking NEW as per JLP's comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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?
Assignee | ||
Updated•24 years ago
|
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 6•24 years ago
|
||
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...)
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•