window.frames is not updated when iframe name is changed |
||||||||
Issue description
Chrome Version : 54.0.2840.71
URLs (if applicable) : See below test file.
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari: Not tested
Firefox: PASS 49.0.2
Edge: FAIL 38.14393.0.0
What steps will reproduce the problem?
(1) Load the below test file.
(2) Enter a new iframe name in the text field and click the "Set frame name" button. This changes the iframe name via document.getElementById('subframe').name = 'newname'.
What is the expected result?
The values for window.frames[0].name and document.getElementById('subframe').name should match after setting document.getElementById('subframe').name = 'newname'.
What happens instead?
The value for window.frames[0].name is not updated to 'newname'. Instead, it always returns the name that existed when the iframe tag was created.
This behaves as expected in Firefox but also fails in Edge. I have not reviewed the spec to determine if a specific behavior is expected/required.
Test file:
<html>
<head>
<script>
function outputFrameNames() {
var output = "window.frames[0].name = " + window.frames[0].name + "\n" +
"document.getElementById('subframe').name = " + document.getElementById('subframe').name + "\n";
document.getElementById('output').value = output;
}
function changeFrameName() {
document.getElementById('subframe').name = document.getElementById("name").value;
outputFrameNames();
}
</script>
</head>
<body onload="outputFrameNames()">
<iframe src="" name="name1" id="subframe" width="10" height="10"></iframe>
<br/>
<input type="text" id="name">
<input type="button" onclick="changeFrameName();" value="Set frame name">
<br/>
<textarea rows="10" cols="60" id="output"></textarea>
</body>
</html>
,
Oct 31 2016
This is an interesting one. I don't actually see anything in the HTML spec about indexing frames by name. In theory we try to update this collection when the name attribute changes, see https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLCollection.cpp?sq=package:chromium&rcl=1477898213&l=146 Would be interesting to know: ... what WebKit does. ... whether this is a regression and if we broke it.
,
Oct 31 2016
,
Nov 1 2016
dcheng, creis: it looks like HTML should forward sets to an iframe's name attribute to the content window's name property, even cross origin? Do you know any history here or have concerns with that? Thanks Domenic for the spec link. Can someone report this bug to Edge and check Safari? Is there a web platform test for this? This looks like a Chrome bug because: <https://html.spec.whatwg.org/#the-iframe-element:browsing-context-name> "Whenever the name attribute is set, the nested browsing context's name must be changed to the new value. If the attribute is removed, the browsing context name must be set to the empty string." I notice if we do: document.getElementById('subframe').contentWindow.name then the window.frames collection is updated. So maybe the iframe name attribute setter isn't pushing the change to the browsing context. Here's where we're probably failing to do that: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp?sq=package:chromium&rcl=1477941524&l=109 This implies that different origins can communicate by setting name. Interesting. Here's the window's named attribute getter; I believe it would work if changing that attribute pushed the new name to the nested browsing context: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/custom/V8WindowCustom.cpp?q=V8WindowCustom&sq=package:chromium&l=286 Note that we correctly push iframes in and out of the Document's named property set per <https://html.spec.whatwg.org/#dom-tree-accessors> "The supported property names of a Document object ... consist of ... the value of the name content attribute for all applet, exposed embed, form, iframe, img, and exposed object elements ..."
,
Nov 1 2016
This hasn't ever worked, AFAIK: for whatever reason, we only plumb window.name changes through in Chrome. Of course, every browser behaved differently in this area when I checked in the past: https://github.com/whatwg/html/issues/257 I think we do want to fix it at some point, so if anyone's interested in fixing this, please let me know =)
,
Nov 1 2016
,
Nov 1 2016
,
Nov 1 2016
FWIW the cross-origin case is specified elsehwere, although it depends on those mechanisms: https://html.spec.whatwg.org/#windowproxy-getownproperty
,
Nov 1 2016
Safari version 9.1.1 (11601.6.17) tested on OS X 10.11.5 (15F34) behaves the same as Chrome.
,
Nov 2 2016
Safari has made some fairly extensive changes to their Window bindings recently; I wouldn't trust anything but their tech preview builds.
,
Aug 22 2017
Bulk disowning per sshruthi's email about bug triage best practices.
,
Oct 1 2017
Issue 766979 has been merged into this issue.
,
Oct 12 2017
See issue 632243 which is related (but for <object> tag I guess)
,
Dec 5 2017
,
Dec 5
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 6
It seems this works correctly with Chrome 71 Stable. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by marshall@chromium.org
, Oct 28 2016