- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 7 Jan 2013 17:23:12 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: whatwg <whatwg@lists.whatwg.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Maybe this got sorted out later in this thread, but I believe that's what WebKit does. Adam On Sat, Dec 15, 2012 at 5:33 PM, Jonas Sicking <jonas@sicking.cc> wrote: > An "easy" solution would be to just return null for .contentDocument > in the case of cross-origin iframes. > > / Jonas > > On Sat, Dec 15, 2012 at 10:43 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> Ccing whatwg because that's where the whole "origin" thing is currently >> defined. >> >> Consider this testcase: >> >> <iframe src="http://w3.org"></iframe><script> >> window.onload = function () { >> try { >> var doc = document.querySelector("iframe").contentDocument; >> var list = document.getElementsByTagName.call(doc, "*"); >> alert(list.item(0).textContent); >> } catch (e) { >> alert(e); >> } >> }</script> >> >> This throws in Safari, Chrome, Firefox, and Opera, all on the >> "getElementsByTagName.call" bit (except when loaded via file:// in Safari, >> in which case it actually lets you read all data from random website in the >> iframe). >> >> But I see nothing in the specs that requires this behavior, or indeed even >> allows it. The security bits currently in the html spec talk about property >> access on cross-origin Document and Window, but in this case there is no >> property access happening on them per se... >> >> In any case, this needs to be defined somewhere. >> >> -Boris
Received on Tuesday, 8 January 2013 01:24:09 UTC