Martijn Pieters Reporter
	Description • 22 years ago

After removing and re-adding the top-level frameset node from the DOM, the
window.frames object is severely futzed.

For example, any window.frames[name].location object is an invalid pointer. A
testcase follows.

	Martijn Pieters Reporter
	Comment 1 • 22 years ago

Reproducable: always

To reproduce:

 - Load testcase

   It'll pop up an alert box with the location.href value of the left-hand
frame.

 - Click OK.

 - Now the javascript code will remove and re-add the top-level frameset node
(removeChild and appendChild calls).

 - Two attempts are made to read the location.href again; one through a timeout
to give the browser a chance to load the frames again, one immediatly. Two
identical exceptions are thrown, both NS_ERROR_INVALID_POINTER.

Other informal tests have shown the window.frames collection to be severely out
of sync.

Bug found in search for a work-around for bug #170730.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 22 years ago

happens on Linux too.

	Johnny Stenback (:jst)
	Comment 3 • 22 years ago

Mass-reassigning bugs to dom_bugs@netscape.com

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 20 years ago

The real problem here is that the window.whatever name is stale.... Are we
defining it on the JSObject or something, so that XPConnect isn't asked again
after the first time?

	mgbrake
	Comment 5 • 19 years ago

FROM FAQ at: http://developer.mozilla.org/en/docs/DOM:window.open

 I can not access the properties of the new secondary window. I always get an error in the javascript console saying "Error: uncaught exception: Permission denied to get property <property_name or method_name>. Why is that?
    It is because of the cross-domain script security restriction (also referred as the "Same Origin Policy"). A script loaded in a window (or frame) from a distinct origin (domain name) cannot get nor set properties of another window (or frame) or the properties of any of its HTML objects coming from another distinct origin (domain name). Therefore, before executing a script targeting a secondary window, the browser in the main window will verify that the secondary window has the same domain name. 
    More reading on the cross-domain script security restriction: http://www.mozilla.org/projects/security/components/same-origin.html 

Firefox 1.5 is not currently allowing access to other frames using the window.parent.frames[x] now even if the frame is the SAME domain, which was working fine prior to 1.5

 

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 19 years ago

that has nothing to do with this bug.  If you have some sort of problem related to window.parent, please file a _new_ bug on it (and cc me on this new bug).

	Dhruba Bandopadhyay
	Comment 7 • 18 years ago

Load up main.html. Click on each link and feel free to click on the same link more than once. Clicking on a link dynamically creates an instance of a IFRAME (using JavaWin). Clicking on the same link whilst the instance is there just refocuses on the already-created instance window.

Click on close (the small red aqua drop) and this destroys (or removes IFRAME node from DOM).

Click on the same link again and examine the debug window. Both the JavaScript & Form elements are not created again, in Mozilla Firefox that is.

Internet Explorer is fine.

	Alice0775 White
	Comment 14 • 11 years ago

I cannot reproduce the problem in Firefox22.0 and later.

Fixed window(m-i)
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/22b3fa2e22c1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130314 Firefox/22.0 ID:20130314223435
Fixed:
http://hg.mozilla.org/integration/mozilla-inbound/rev/cfa16b1c70a3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130314 Firefox/22.0 ID:20130314223935
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=22b3fa2e22c1&tochange=cfa16b1c70a3

This was fixed by Bug 850517