This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML5 says that the dynamic nested browsing context properties are available cross-origin on Window, but that appears to be indexed access only, not named frame access. I just put together a testcase: http://people.mozilla.com/~bholley/testcases/cross-origin-named-window/test.html This testcase returns true in Firefox, Safari, Chrome, Opera (Presto), and IE9. I don't have a copy of IE10 lying around, but it would be good if someone checked that. Do we have a reason to believe that the current spec is web-compatible here?
This is just an oversight in the spec. Extra questions: - Are they enumerable? - Are named properties other than child browsing context names accessible? - If not, are they distinguishable from names that otherwise don't exist? (I can test this if you don't have the bandwidth to, but since you've already made a cross-origin test case, you might be able to get answers quicker than me!)
(In reply to comment #1) > This is just an oversight in the spec. > > Extra questions: > - Are they enumerable? I updated the testcase a little bit to poke on this. Looks like they're not in Chrome/Safari, but it's a bit tricky to determine this from script in Gecko, because enumerating a cross-origin window seems to throw a security exception. I'm pretty sure it didn't used to, so I'm going to look into that. > - Are named properties other than child browsing context names accessible? As mentioned on IRC, I think it would be a major security problem if they were.
With the updated testcase IE 10 seems to have the same results as Firefox: the script throws an access error on line 9. On Chrome I get an alert with the results "Cross-Origin Named Frame Access Works: true\nEnumerable: false".
(In reply to comment #3) > With the updated testcase IE 10 seems to have the same results as Firefox: > the script throws an access error on line 9. On Chrome I get an alert with > the results "Cross-Origin Named Frame Access Works: true\nEnumerable: false". I've filed [1] for this. Hixie, can you confirm my interpretation of the spec behavior on that bug? https://bugzilla.mozilla.org/show_bug.cgi?id=862380
Bobby, can you summarise what you think should change in the spec for this?
(In reply to comment #5) > Bobby, can you summarise what you think should change in the spec for this? Sorry for the delay here. Named subframes should be cross-origin accessible just like indexed subframes (they're essentially a property of the browsing context). They are not enumerable, because cross-origin windows are not enumerable.
Hmm. Does getOwnPropertyNames show them? Named subframes are normally own props of the NamedPropertiesObject, but in the cross-window access case it's not clear to me whether they should appear to be own properties of the WindowProxy or not.
Largely because the spec doesn't actually define what things like getOwnPropertyDescriptor and Object.getPrototypeOf() should do on the WindowProxy in a way that's compatible with exposing the named subframes (and arguably not in any way at all, because afaict a strict reading of the spec would allow getting the proto cross-origin which can't possibly be the intention).
*** Bug 23218 has been marked as a duplicate of this bug. ***
Okay, it seems that in order to fix this we should turn "the browsing context name of any child browsing context of the active document whose name is not the empty string" into its own thing so that it can be referenced both by the Window's named properties definition and by the set of properties available cross-origin. Does that make sense? https://github.com/annevk/html-cross-origin-objects should then take care of the rest.
Superficially, that sounds fine. My opinion as of the last time I thought about this issue in detail is summarized in comment 6.
https://github.com/whatwg/html/pull/544