User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 Build Identifier: When I'm creating iframe with src equal to following: data:text/html;plain,<!doctype html><html><body><script>alert(document.cookie);</script>hello world!</body></html> and open page - it displays parent window's cookies (while has no access to window.parent variable). Reproducible: Always Steps to Reproduce: 1. Create iframe with src = "data:text/html;plain,<!doctype html><html><body><script>alert(document.cookie);</script>hello world!</body></html>" on any non-local page. 2. Open page and add any cookie 3. Refresh page Actual Results: I see cookie of parent window Expected Results: Not to see cookie as in Chrome and Opera.
I believe this is the intended behavior: a data: document inherits the domain and privileges of the site which opened it, by design.
I understand you, but they have different hostname as I see. Am I wrong? Chrome and Opera disallows usage of document.cookie, and Firefox disallows usage of window.parent. Probably you should enable window.parent in this case. But at look at this like it's a variant of cheap content sandboxing (That's how I'm using it on : http://mapchat.me/ )
Actually, I'm embedding content here: http://mapchat.me/#/point/25.77/-80.21
> Probably you should enable window.parent in this case. window.parent should work in this case, and does for me. Again, the data: URI has the same permissions as the thing that loaded it. Yes, this is different from what Webkit and Opera do. But it's what we've done for close to 10 years now, and is well-known behavior. Attempts to use data: URIs for "sandboxing" are just broken. Removing security-sensitive flag, since this is all well-known documented behavior.
Can you please post here a link to any specification document, that describes such behavior? I don't see any benefits of such behavior, it can't be usable b/c of non-existance of browser's compatibility.
Sorry, I wanted to say, that it's not cross-browser, and since that is not usable.
Hmm. We used to have documentation for this on mozilla.org, but I can't find it right this second. > I don't see any benefits of such behavior The ability to dynamically create documents that you can then actually interact with? > it can't be usable b/c of non-existance of browser's compatibility Yeah, it's too bad Opera and Webkit decided to do something incompatible.... ;) For what it's worth, there is discussion about standardizing the behavior here in the whatwg, or has been in the past. The fact that @sandbox exists will probably matter for your sandboxing use case.
> The ability to dynamically create documents that you can then actually interact with? Why not just create regular html elements? :) Sandboxing using this technique gives much more benefits to me: you can not only embed elements, but do JSONP requests in this iframes and than pass data to parent window, using window.postMessage().
> Why not just create regular html elements? :) Because it can be much slower? Seriously, what you're trying to do doesn't work and hasn't worked for over 10 years. If you need sandboxing, you need a different approach.
Heh. Like to see, that Mozilla is not for cross-browser compatibility ;) It's like posting bugs to Microsoft about Internet Explorer - noone cares about cross-browser functionality. Anyway, thank you for answering.
Mozilla is for it, which is why we are having the spec discussion.
We're not for unilaterally changing our longstanding behavior, breaking existing content in the process, to try to match other browsers if they won't tell us what, exactly, they implement. We're all for working with them to figure out a spec for the behavior that we all agree on, and then implementing it. Which is what we're doing.
Is there any place where I can subscribe for discussion of this spec?
firstname.lastname@example.org should work. You may want to search the archives at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ to see what's already been said in the past.