Closed
Bug 103353
Opened 24 years ago
Closed 23 years ago
Crash when frame or iframe has SRC="javascript:window.close()"
Categories
(Core :: Layout, defect, P1)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: donguana, Assigned: attinasi)
References
Details
(Keywords: crash)
Attachments
(3 files)
The following code will crash mozilla. I tried it with 0.9.4 and the nightly
build of oct 5.
<FRAMESET COLS="100%">
<FRAME SRC="javascript:window.close()">
</FRAMESET>
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
Comment 3•24 years ago
|
||
Confirming crash; Mozilla trunk binaries 20011004xx WinNT, Linux, Mac 9.1.
This has nothing to do with JS Engine; reassigning to Layout. OS : Win --> All.
Assignee: rogerl → attinasi
Status: UNCONFIRMED → NEW
Component: Javascript Engine → Layout
Ever confirmed: true
OS: Windows NT → All
QA Contact: pschwartau → petersen
| Assignee | ||
Comment 4•24 years ago
|
||
Accepting: the mContent is null in the frameset frame - adding code to handle that.
| Assignee | ||
Comment 5•24 years ago
|
||
Never mind that - this is much worse. The frameset frame is being destroyed,
then later reflowed. Reflowing a destroyed frame is generally not a good idea...
| Assignee | ||
Comment 6•24 years ago
|
||
| Assignee | ||
Comment 7•24 years ago
|
||
This kills me too:
<body>
<iframe SRC="javascript:window.close()"></iframe>
</body>
The stack is different, pointing to some nasty recursion, but I think the
underlying problem is really the same, namely that the Frame's Init method is
what loads the URL, and in this case it ends up closing the window, destroying
all the frames, and leaving the stack a giant heap of garbage.
| Assignee | ||
Comment 8•24 years ago
|
||
rewording of summary
Summary: Crash when using javascript withing frame attribute → Crash when frame or iframe has SRC="javascript:window.close()"
| Assignee | ||
Comment 9•24 years ago
|
||
Moving this edge-case out to later milestone. I doubt there are many pages
written like this (unless they are trying to do nasty things).
Target Milestone: mozilla0.9.6 → mozilla1.0.1
| Assignee | ||
Comment 10•24 years ago
|
||
Related to bug 103997
Comment 11•24 years ago
|
||
*** Bug 99001 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
*** Bug 97015 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 13•23 years ago
|
||
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1
I will be pulling bugs from 'future' milestones when scheduling later work.
Target Milestone: mozilla1.0.1 → Future
Comment 14•23 years ago
|
||
Good news I think. Works for me.
I tested it with
Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
and it crashed so I could be sure that the bug reproduces on my computer.
Then I tested the case again with both of the following versions and it didn't
crash:
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0rc2) Gecko/20020428
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0rc2) Gecko/20020510
Comment 15•23 years ago
|
||
WFM too (WinXP/1.0.0 aka 2002053012)
please close it :)
Comment 16•23 years ago
|
||
Closing as WFM based on comment 14 and comment 15
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•