NEW 36459
Assigning to window.name in an iframe breaks link targets in containing document. 
https://bugs.webkit.org/show_bug.cgi?id=36459
Summary Assigning to window.name in an iframe breaks link targets in containing docum...
Peter Abrahamsen
Reported 2010-03-22 12:38:35 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2010-03-22 17:17:37 PDT
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.
Peter Abrahamsen
Comment 2 2010-03-22 18:44:57 PDT
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.
Alexey Proskuryakov
Comment 3 2010-03-22 19:10:54 PDT
> It seem like an access violation Yes, I didn't think about this angle of the issue.
Adam Barth
Comment 4 2010-03-23 13:56:35 PDT
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.
Alexey Proskuryakov
Comment 5 2010-03-23 14:18:24 PDT
As mentioned in comment 1, assigning to "var name" also changes window.name in Firefox.
Alexey Proskuryakov
Comment 6 2010-03-23 14:19:07 PDT
Sorry, please ignore the above comment as irrelevant.
Peter Abrahamsen
Comment 7 2010-03-23 16:03:58 PDT
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?
Alexey Proskuryakov
Comment 8 2012-02-01 10:08:02 PST
*** Bug 41003 has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 9 2012-02-01 10:08:36 PST
See also: bug 19967 (likely a root cause of this issue).
Note You need to log in before you can comment on or make changes to this bug.