User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20141206030202 Steps to reproduce: have an iframe with id="foo" on the page Actual results: in a script, window.frames["foo"] is a reference to the iframe element itself Expected results: window.frames["foo"] should reference document.getElementById("foo").contentWindow Documentation here: https://developer.mozilla.org/en-US/docs/Web/API/Window.frames#Syntax This is also reported to the Chromium bug tracker: https://code.google.com/p/chromium/issues/detail?id=438923 A jsfiddle is here: http://jsfiddle.net/npup/cra81rmy/1/ /p
<https://html.spec.whatwg.org/multipage/#named-access-on-the-window-object> defines that this behaviour only happens if the name is "the browsing context name of any child browsing context"; <https://html.spec.whatwg.org/multipage/#attr-iframe-name> defines that only the |name| attribute affects the "browsing context name".
(In reply to :Ms2ger from comment #1) I see what those document say, but html5 is not supposed to break implementations from html4, is it? Please consider the implications of keeping this. Chromium is looking into it, just saying (https://code.google.com/p/chromium/issues/detail?id=438923#c1). /p
Are you saying that this behaviour changed in browsers?
(In reply to :Ms2ger from comment #3) > Are you saying that this behaviour changed in browsers? Yes it has changed. And the behaviour with window.frames["foo"] referencing a window instead of an (i)frame element has been relied upon, reportedly. Oddly, MDN notes support what I described, but when i ran some tests it seems Firefox never did this! Test results: IE: works in all versions tested -> 6-11 Chrome: works in versions < 35 Safari: works in all versions tested -> 4, 5, 5.1, 6, 6.1, 6.2, 7, 8 Opera: works in versions < 22 Firefox: never worked, at least not since version 3.0 Test page used: http://envall.se/sandbox/broken-frames.html /p
Checking up on it, i saw that Firefox returned `null` for the window.frames["foo"] reference up to version 18. So that behaviour has changed in Firefox, even though it never seem to have worked as the MDN note says. /p