Mike Gratton Reporter
	Description • 22 years ago

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.

	Mike Gratton Reporter
	Comment 1 • 22 years ago

See the URL for a test case.

This may be the cause of bug: 58684

Adding some keywords.

	Matt Foster
	Comment 2 • 22 years ago

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.

	Gérard Talbot
	Comment 3 • 22 years ago

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.

	Johnny Stenback (:jst)
	Comment 4 • 22 years ago

Mass-reassigning bugs to dom_bugs@netscape.com

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 20 years ago

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

	Mike Gratton Reporter
	Comment 6 • 20 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 20 years ago

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?

	Mike Gratton Reporter
	Comment 8 • 20 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 9 • 20 years ago

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?

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 20 years ago

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...

	Bob Clary [:bc] (inactive)
	Comment 11 • 20 years ago

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.

	Mike Gratton Reporter
	Comment 13 • 20 years ago

Attached the test case referenced in the URL field

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 20 years ago

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....

	Boris Zbarsky [:bzbarsky]
	Comment 15 • 12 years ago

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.

	catalandav
	Comment 17 • 12 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 18 • 12 years ago

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

	catalandav
	Comment 19 • 12 years ago

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.

	Mina Almasry
	Comment 20 • 11 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 21 • 11 years ago

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)?

	Mina Almasry
	Comment 22 • 11 years ago

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...?

	Boris Zbarsky [:bzbarsky]
	Comment 23 • 11 years ago

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

	Mina Almasry
	Comment 24 • 11 years ago

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?

	David Bruant
	Comment 25 • 11 years ago

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

	Josh Matthews [:jdm]
	Comment 26 • 11 years ago

(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

	Boris Zbarsky [:bzbarsky]
	Comment 27 • 11 years ago

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.

	Mina Almasry
	Comment 28 • 11 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 29 • 11 years ago

Hmm.  Did this get fixed in bug 850517?

	Josh Matthews [:jdm]
	Comment 30 • 11 years ago

Part 4 in that bug sure looks likely.

	Boris Zbarsky [:bzbarsky]
	Comment 31 • 11 years ago

Looks like this got fixed, yes.

	Bobby Holley (:bholley) Assignee
	Comment 32 • 10 years ago

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