Closed Bug 1839 Opened 26 years ago Closed 25 years ago

frame reference

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: godfrey.lee, Assigned: joki)

References

Details

From the window containing the frameset, you can refer to window.frames["FX"]
but not window.FX.

See code below:

FR.htm
------
<HTML>
<HEAD>
<SCRIPT LANGUAGE=JavaScript>
window.name="FR";
var FXloaded=0;
var FTloaded=0;
function sync(){
	if(FXloaded==0 || FTloaded==0)
		return;
	alert("sync");
	window.frames["FT"].sync();
	self.FX.sync()}
</SCRIPT>
</HEAD>
<FRAMESET onUnload="defaultStatus=''" ROWS="*,50" frameborder=0 border=0>
<FRAME NAME=FX MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=auto SRC=FX.htm>
<FRAME NAME=FT MARGINHEIGHT=10 MARGINWIDTH=0 SCROLLING=no SRC=FT.htm>
</FRAMESET>
<BODY>

</BODY>
</HTML>


FX.htm
------
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
<!--
function sync(){
	alert("FX Loaded");
}
function init(){
	if(parent.FXloaded!=null){
		parent.FXloaded=1;
		parent.sync();
	}
}
//-->
</SCRIPT>
</HEAD>
<BODY onLoad="init();">
First Frame
</BODY>
</HTML>


FT.htm
------
<HTML>
<HEAD>
<SCRIPT LANGUAGE=JavaScript>
<!--
function sync(){
	alert("FT Loaded");
}
function init(){
	if(parent.name=="FR"){
		parent.FTloaded=1;
		parent.sync();
	}
}
//-->
</SCRIPT>
</HEAD>
<BODY onLoad="init();">
Second Frame
</BODY>
</HTML>
Assignee: mccabe → vidur
This sounds like one of those navigator-and-ie-aren't-the-same issues.

They're different.

But perhaps this is a DOM level 1 conformance issue, if the bug is against the
new layout browser.

Vidur, care to comment?

(Also, shouldn't there be a 'Document Object Model' component in bugsplat to
assign things to, to correspond with the entry in owners.html?  I'd like to
assign this bug to that component.)
Assignee: vidur → joki
Tom, I'm reassigning this to you. You can get window.FX working by introducing a
Window NamedItem(in DOMString name) for the Window interface.
*** Bug 1674 has been marked as a duplicate of this bug. ***
Well, I actually did a trial implementation by adding NamedItem to Window. The
good news is that it works. The bad news is that it's horribly inefficient since
a lot of stuff goes through a window's getProperty() and we're doing unnecessary
lookups for each property lookup, frame-related or otherwise. We need to come up
with a better implementation of this.
*** Bug 1752 has been marked as a duplicate of this bug. ***
Setting all current Open/Normal to M4.
QA Contact: 4590
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA Contact: 4590 → 4015
DOM bugs are not my problem.
QA Contact: 4015 → 4616
QA contact re-assigned according to the product areas we're currently working
on.
Status: NEW → ASSIGNED
Target Milestone: M4 → M5
Moving this to M5.  I won't get to it tomorrow.
*** Bug 3011 has been marked as a duplicate of this bug. ***
Target Milestone: M5 → M6
Target Milestone: M6 → M7
Moving out to M7
Hi guys,
I would like to know if this bug is currently fixed but you are keeping it open
so you can provide a better implementation later.
I have a large DHTML application that I would like to start testing on
gecko/mozilla, and would like to know if I need to avoid this construct or not.

Thanks,
Godfrey Lee
*** Bug 6789 has been marked as a duplicate of this bug. ***
I believe this one is indeed still broken.
Component: JavaScript → HTMLFrames
*** Bug 7647 has been marked as a duplicate of this bug. ***
*** Bug 7260 has been marked as a duplicate of this bug. ***
Got a fix.  Waiting for a slightly greener tree to put it in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fix checked in.
Status: RESOLVED → VERIFIED
Working fine now. Marining as verified.
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.