Consider the following two small HTML documents: <html> <head><title>A</title></head> <body> <iframe src="b.html" name='b'></iframe> <a href="http://www.google.com/" target="b">Google</a> </body> </html> <html> <head><title>B</title></head> <body> <script> var name = 'fnord'; </script> </body> </html> The var statement (WHY does a var statement in a script tag assign to window?) changes the b's window.name, which breaks the Google link. The W3C HTML DOM spec says that the 'name' attribute of an iframe element "assigns a name to the current iframe". I can't find anything suggesting that this attribute has anything to do with the contained window's name property, yet in WebKit, they seem to be the same. Neither IE nor FireFox appear to exhibit this behavior.
I can confirm that behavior on this test case is different between Safari and Firefox. This may or may not be intentional though. The behavior of assigning to name matches Firefox behavior (assigning to the variable also changes window.name instead, and window name is inherited from iframe element name). But it seems that Firefox looks for target by iframe element name, and not by frame name.
Thanks, Alexey. The Firefox behavior really seems right to me. It seem like an access violation to me that a third-party site in an iframe could inadvertently change the behavior of a containing window which is not making any attempt to access the iframe's internal state. And you're right about var statements in script blocks affecting window. That also seems very wrong to me, but it's clearly The Way It Is.
> It seem like an access violation Yes, I didn't think about this angle of the issue.
Window names existing a global namespace. Trying to stop an iframe from screwing around with name-targeted navigation would be tricky. We should match Firefox as closely has possible here. Name targeted navigations are really fragile. We should test the priorities between the following three names for a frame: 1) The iframe's "name" attribute. 2) Assigning to "window.name". 3) Declaring a global "name" variable. 4) Declaring a global "name" function. We should also test both the same-origin and the cross-origin scenario. My guess is that the bug is that we're making "var name" assign to window.name instead of shadowing the DOM property with the JavaScript variable.
As mentioned in comment 1, assigning to "var name" also changes window.name in Firefox.
Sorry, please ignore the above comment as irrelevant.
Can anyone think of a workaround here? Maybe I could trap the navigation click in JS, find the iframe through the DOM, and assign to its location, or its src attribute?
*** Bug 41003 has been marked as a duplicate of this bug. ***
See also: bug 19967 (likely a root cause of this issue).