If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Broken references via window.frames

UNCONFIRMED
Unassigned

Status

()

Core
DOM: Core & HTML
UNCONFIRMED
3 years ago
3 years ago

People

(Reporter: P. Envall, Unassigned)

Tracking

37 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
<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".
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

3 years ago
(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
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Are you saying that this behaviour changed in browsers?
Flags: needinfo?(petter.envall)
(Reporter)

Comment 4

3 years ago
(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
Flags: needinfo?(petter.envall)
(Reporter)

Comment 5

3 years ago
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
You need to log in before you can comment on or make changes to this bug.