161061 - Setting an iframe's "name" property not reflected in the iframe's "window.name"

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Mike Gratton]

Normally, you can access an iframe's "name" attribute/property via the
"window.name" property from javascript in the iframe's document. This works fine
for iframes defined by the HTML page itself, it also works fine for dynamically
created iframes, provided you set the "name" property *before* you add the new
element to the parent document.

If, however, you set the "name" property *after* you insert the new element, you
cannot access the frame's name via "window.name".

This is a regression, which appeared somewhere between 0.9.4 and 0.9.5, so
Netscape 6 isn't effected, but Netscape 7 is.

Comment 1

[Mike Gratton]

See the URL for a test case.

This may be the cause of bug: 58684

Adding some keywords.

Comment 2

[Matt Foster]

Is this bug the reason that I get the following JavaScript error:

Error: uncaught exception: Permission denied to get property Window.name

At this URL:

http://isl715.nws.noaa.gov/tdl/icwf/user_guide_ifps11/

Just checking, so I don't file a dupe.

Comment 3

[Gérard Talbot]

Attachment: Same testcase as the given URL except appendChild() and frames[k].name are used

The name attribute of dynamically created iframes can still be set after the
DOM element insertion in the document provided that one uses 
frames[k].name = nameOfIframe;

Note that the id attribute cannot be a valid one for a script element. So,
instructions/assignments like 
id="insertion-point1" and 
var insertionPoint = document.getElementById("insertion-point1");
are not valid. Therefore valid code would indicate using only
appendChild() and 
frames[k].name = nameOfIframe;

I'm not sure this bug is valid since the
frame variable is a local variable pointing to an element already inserted
into the document. Using 
frames[k].name = nameOfIframe;
is independent of local variables scope and declarations.

Anyway, for sure, there is a valid suitable workaround if this bug is valid.

Comment 4

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 5

[Boris Zbarsky [:bzbarsky]]

The testcase worksforme in a current trunk build.  Is this still a problem?

Comment 6

[Mike Gratton]

It seems to still be broken, using 2004120504/Linux (GTK2) and a new profile.

The second iframe in the testcase should contain the text:

   this.name: frame2

   window.name: frame2

But the name is still blank for me.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Odd... the testcase worksforme with a 2004-12-05-07 GTK1 nightly and a GTK2
self-build from a few days ago... can you reproduce the problem 100% reliably?

Comment 8

[Mike Gratton]

Sorry for the delay. Yep, I click on the URL link above and the second frame is
still b0rked. I just tried again:

- downloaded new daily build (mozilla-i686-pc-linux-gnu-gtk2+xft.tar.gz, 2005031101)
- started mozilla
- created new profile
- opened bug page
- clicked URL link

Still broken.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Oh, I see.  I was looking at the testcase attached to the bug, not the URL field...

The testcase attached to the bug sets the name on the window inside the iframe,
not on the iframe itself.

We could probably make all "name" attr changes on the iframe change the name on
the window (right now the window name is set when we create the frame loader,
which means on insertion into document at the moment).  jst, bc, peterv, does
that sound like a good idea?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 112654 [details]
Same testcase as the given URL except appendChild() and frames[k].name are used

And Mike, you may want to attach your testcase to the bug...

Comment 11

[Bob Clary [:bc] (inactive)]

Opera 7.6 appears to set the iframe's window's name to match the value set on
the iframe element in both cases. MSIE 6 does not for either case. I don't think
this would be an interoperable win unless future versions of MSIE match Opera's
behavior, but it would at least be consistent if we were to propagate (or not)
the iframe's name to the iframe's window object consistently regardless of the
order of setting the property vs. insertion into the document.

Comment 12

[Mike Gratton]

Attachment: Testcase iframe document

Comment 13

[Mike Gratton]

Attachment: Main testcase document

Attached the test case referenced in the URL field

Comment 14

[Boris Zbarsky [:bzbarsky]]

Well, if we kept the current setup but fixed our (known) bug that the
subdocument window only exists if the frame is in a document, sounds like we'd
have behavior similar to IE's....

Comment 15

[Boris Zbarsky [:bzbarsky]]

Spec at www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html says:

  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.

Sounds like we should do that.

Comment 17

[catalandav]

I would be happy to work on this if it hasn't yet been assigned to anyone else.

Comment 18

[Boris Zbarsky [:bzbarsky]]

It hasn't, no.  Go for it!  Let me know if you have any questions.

Comment 19

[catalandav]

Great, thanks. This is actually my first ever contribution to an open source project so I may need some guidance.  I'm reviewing some of the documentation on working with the Mozilla source code right now, and will post my questions once I have a better handle on this.

Comment 20

[Mina Almasry]

Hey bz, do you mind mentoring me on this too? Where do I start with this?

Comment 21

[Boris Zbarsky [:bzbarsky]]

Basically, whenever SetAttr or UnsetAttr happen on HTMLIFrameElement or HTMLFrameElement for the "name" attribute, you want to update the name of the docshell if the frame has one.

So start in the attribute set/unset functions in nsGenericHTMLFrameElement.cpp (and add them as needed)?

Comment 22

[Mina Almasry]

Okay with no work from me, my build of firefox works for the URL and and "Main testcase document". By works I mean I see both the names of frame1 and frame2

For Testcase iframe document I see nothing, but that's the same behavior as opera.

I am at chageset 128303 from april 11.

Is this bug still there then...?

Comment 23

[Boris Zbarsky [:bzbarsky]]

See comment 9.  The testcases attached there have nothing to do with this bug; they should probably be marked obsolete.

Comment 24

[Mina Almasry]

I have looked in  HTMLIFrameElement, HTMLFrameElement, and nsGenericHTMLFrameElement but I can't find the docshell you mentioned. Can you please clarify where is the docshell I need to update?

Comment 25

[David Bruant]

I've been recently dreaming that cross-origin iframes might be able to run in parallel than the main page in Servo [1]. I'm not entirely sure, but I believe that this is the point of Blink's out-of-process iframes [2].
I think that it all only works if there is no synchronous communication between an iframe and its parent.
I've discussed with Josh Matthews last week-end and he suggested that iframe.name was a way for content to communicate synchronously with an iframe, even a cross-origin one.

If this bug means that this communication channel is broken, it means that the web does not depend on it and it could make sense to not repair it looking forward.
Also, apparently, it also doesn't work anymore in Chrome (I'll need to check the details) [3].

Anyway, I'd be happy to see this bug WONTFIX'ed if that's possible.


[1] https://groups.google.com/d/msg/mozilla.dev.servo/LQ46AtKp_t0/plqFfjLSER8J
[2] http://www.chromium.org/developers/design-documents/oop-iframes
[3] https://twitter.com/getify/status/351408551408836609

Comment 26

[Josh Matthews [:jdm]]

(In reply to Mina Almasry from comment #24)
> I have looked in  HTMLIFrameElement, HTMLFrameElement, and
> nsGenericHTMLFrameElement but I can't find the docshell you mentioned. Can
> you please clarify where is the docshell I need to update?

I'm presuming it's the one obtained from mFrameLoader: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLIFrameElement.cpp#229

Comment 27

[Boris Zbarsky [:bzbarsky]]

David, please feel free to raise spec issues as needed.  That said, the tweet you cite is about direct sets of window.name, not about setting the @name of an <iframe>.  Please feel free to check the details of how @name behaves in different browsers, of course.

Comment 28

[Mina Almasry]

Uh... I'm not sure what happened since I last looked at the URL test case, but the nightly build for linux and mac both work fine for me now.

- Build firefox
- Open the link in the URL field in nightly
- The first box says frame1
- The second box says frame2

Comment 29

[Boris Zbarsky [:bzbarsky]]

Hmm.  Did this get fixed in bug 850517?

Comment 30

[Josh Matthews [:jdm]]

Part 4 in that bug sure looks likely.

Comment 31

[Boris Zbarsky [:bzbarsky]]

Looks like this got fixed, yes.

Comment 32

[Bobby Holley (:bholley)]

I think the tests in bug 850517 should cover us here.