Closed Bug 130113 Opened 23 years ago Closed 11 years ago

top.window.close() fails when a frame is named "close"

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mikeg, Unassigned)

References

Details

(Keywords: compat)

Attachments

(3 files)

frame1.htm
(deleted), text/html
Details
frameset.htm
(deleted), text/html
Details
frame2.htm
(deleted), text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; H010818; T312461)
BuildID:    20011128 

I have a window with 2 frames which is open from window.open. In NN4 and IE it 
closes fine with top.window.close(). IN NN6, it throws an error:
Error: top.window.close is not a function

if I use window.close(), it works, but it doesn't work in NN4 OR IE.

Reproducible: Always
Steps to Reproduce:
1.Create 3 pages. one is a frameset the other 2 are frames.
2.one of the frames calls the following: top.window.close();
3.open the frameset page from another page by window.open
4.try closing.

Actual Results:  error is thrown and window doesn't close

Expected Results:  close the window
Browser, not engine. Reassigning to DOM Level 0.

Mike, is there a URL we can try? If so, could you put it in the
URL field above? Otherwise, could you paste a reduced testcase here,
in-line. Just something like this:


FRAMESET PAGE
<html>
 etc. with the call to window.close()?

FRAME 1
<html> 
  etc.

FRAME 2
<html> 
  etc.

TEST PAGE (?)
<html>
  etc. with the call to window.open() ?


Thanks - then we can save it locally and try it out.
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale
here you go. If you have any questions, feel free to contact me.

[index.htm]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
	<title>Untitled</title>
</head>
<body>
<a href="#" onclick="window.open
('frameset.htm', '', 'width=300,height=300');return false;">Open window</a>

</body>
</html>

[frameset.htm]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
	<title>Untitled</title>
</head>

<frameset rows="50%,50%" frameborder="0" border=0 marginheight="0" 
framespacing="0">
	<frame name="courselist" src="frame1.htm" marginwidth="10" 
marginheight="10" scrolling="auto" frameborder="0">
	<frame name="close" src="frame2.htm" marginwidth="0" marginheight="0" 
frameborder="0" noresize scrolling="no">
</frameset>

</html>

[frame1.htm]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
	<title>Untitled</title>
</head>

<body>
frame1


</body>
</html>

[frame2.htm]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
	<title>Untitled</title>
</head>

<body>
frame2.htm<br>
<a href="javascript:top.window.close()">Doesn't work</a><br>
<a href="javascript:window.close()">Works</a><br>


</body>
</html>

Mike: thanks. I tried this example with Mozilla trunk 20020311xx WinNT,
as well as NN4.7 and IE6. Confirming reported behavior. In Mozilla, 
when I click on the "Doesn't work" link in frame 2, I see the error in the
JS Console that you reported:

            Error: top.window.close is not a function


If I click on the "Works" link in frame 2, I get no error, but the
window does not close - nothing happens. The same is true in NN4.7
and IE6 - nothing happens on the "Works" link. In NN4.7 and IE6, the
"Doesn't work" link works fine, as you reported.


cc'ing Boris because I think he'd be interested in this -
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just to make sure that it is clear: on my N6 (Gecko/20011128 Netscape6/6.2.1), 
link which says "Works" closes the window. 
<frame name="close" ...>

So top.close is the window object corresponding to that frame in Mozilla. Now
(top.window == top) (in both NS4 and Mozilla).  So top.window.close is indeed
not a function.

top.close is _not_ a window object in NS4 in this case, however.
OS: Windows 2000 → All
Hardware: PC → All
Boris is right: if you change

                <frame name="close" ...> 
to              <frame name="closeXXX" ...>

then the "Doesn't work" link functions correctly.

That just leaves one question: why the "Works" link doesn't function
for me in any browser on WinNT, but apparently works for Mike with his
Mozilla build from 20011128: 

        <a href="javascript:window.close()">Works</a>

Does that make sense?
Severity = MEDIUM [No Crash, Severe functional failure, Does not results in 
Cosmetic failure]
Visibility = MEDIUM [Could be real world website usage, Gets one point of 
compatibility with other browsers since it works fine on other browsers. gets 
one more point on compliance with adopted techonology, that is client side JS] 

Priority = Visibility * Severity

Priority = p3

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.
Keywords: qawanted
Priority: -- → P3
Keywords: compat
look at bug #130739, i think it sheds some light on the issue
*** Bug 130739 has been marked as a duplicate of this bug. ***
I think the following set of files and the workaround I found, give better idea 
why the bug happens:
----------------------------------------

3 files, one of them is reused. See Steps to Reproduce.


[frame2.htm]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>Untitled</title></head>
<body>
<script>
var _rndEnd = parseInt(Math.random()*10000);
var winRef = null;
function openWin(whichFile) {
	winRef = window.open(whichFile, "winRef" + _rndEnd, 
	
"resizable=yes,scrollbars=yes,status=no,location=no,directories=no,toolbar=no,me
nubar=no,width=200,height=200,top=100,left=100");

//
winRef = window.open("new.htm", "aaaa", "width:200;height:200");
}

function closeWin() {
	if (winRef!=null && !winRef.closed) {winRef.close();}
}

function closeWinN6() {
	if (winRef!=null && !winRef.closed) {winRef.frames[0].close();}
}

window.onunload = closeWin;
</script>

<a href="javascript:openWin('frameset.htm');">Open Window
(frameset)</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;
<a href="javascript:openWin('frame1.htm');">Open Window (no frameset)</a>
<hr>
<a href="javascript:closeWinN6();">Close Framed Window (Netscape 6
hack)</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;
<a href="javascript:closeWin();">Close Window</a>
</body>
</html>

[frame1.htm]
<html>
<head>
	<title>Untitled</title>
</head>

<body>
frame1



</body>
</html>

[frameset.htm]
<html>
<head>
	<title>Untitled</title>
</head>

<frameset rows="80%,20%" frameborder="0" border=0 marginheight="0" 
framespacing="0">
	<frame name="courselist" src="frame1.htm" marginwidth="10" 
marginheight="10"
scrolling="auto" frameborder="0">
	<frame name="close" src="frame2.htm" marginwidth="0" marginheight="0"
frameborder="0" noresize scrolling="auto">
</frameset>

</html>


Reproducible: Always
Steps to Reproduce:
1.Open frame2.htm. 
2.Click "Open Window (frameset)"
3.Try closing with "Close Window", should get an error.
4.You can close that window with a hack I found (Click on "Netscape 6 hack")
5.If you "Open Window (no frameset)", you will be able to use "Close Window"
*** Bug 180325 has been marked as a duplicate of this bug. ***
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Summary: top.window.close from a window with frames throws an error and doesn't close → top.window.close() fails when a frame is named "close"
jst, caillon, is this similar to bug 222191, or invalid, or something? I can
never figure out the correct resolving order. I should write a doc someday :-P
Attached file frame1.htm (deleted) — 
I see this bug in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20050915, so I attach slightly improved testcase files. Start with frame2.htm
Assignee: general → nobody
QA Contact: desale → general
WFM with the attached test case on Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0.
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Fwiw, this was fixed by making frame names not shadow the proto chain.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: