Closed Bug 1839 Opened 26 years ago Closed 26 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: 26 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.