- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 13 Feb 2009 23:06:25 +0000 (UTC)
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: whatwg <whatwg@whatwg.org>, HTMLWG <public-html@w3.org>
(Please pick one mailing list when replying, so as to reduce cross-posting.) On Thu, 22 May 2008, Boris Zbarsky wrote: > Ian Hickson wrote: > > - by default, content in sandboxed browsing contexts, and any > > browsing contexts nested in them > > How do those nested browsing contexts come about, given that later you say: > > > - content in those browsing contexts cannot create new browsing > > contexts or open modal dialogs or alerts > > ? My summary was under-precise, my apologies. The spec itself seems to be unambiguous here, though let me know if I missed anything. > > have a unique origin > > (independent of the origin of their URI); this can be overriden > > using the "allow-same-origin" keyword > > So the parent page cannot script the contents of the iframe by default, right? Correct. > > - by default, script in those browsing contexts cannot run; this can > > be overriden using the "allow-scripts" keyword > > What happens if the parent page sets window.location to a javascript: URI on > the sandbox iframe? Does the script run? If so, in which browsing context? If the "allow-same-origin" flag is not set, the javascript: doesn't run, as cross-orgin javascript: execution is blocked. If the "allow-scripts" flag is not set, uh, *fixes error in the spec*. Ok, if the "allow-scripts" flag is not set, then javascript: doesn't run, as javascript execution is blocked in sandboxed browsing contexts. > > causes the iframe to size vertically to the bounding box > > of the contents, and horizontally to the width of the container > > I assume that the bounding box is computed after setting the width? No need to assume. :-) The spec text is at: http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless Please do let me know if that is suboptimal. > > and the style sheets that apply to the <iframe> > > must also apply to the contents. > > But the ' ' and '>' combinators don't cross the iframe boundary, right? It's as if the style sheets were imported directly by the inner frame. > > This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the > > general approaches taken. > > As someone else pointed out, this doesn't seem like it would be usable > without some UA sniffing or something, as things stand. Indeed. If someone can come up with a way of making this work in legacy UAs, I'd certainly be happy to change the spec to do that. > > There are various things that this doesn't address yet; e.g. there's > > no way to force (or even allow) a non-seamless iframe to open links in > > the parent window. > > This could be an @sandbox keyword value. Indeed. > > This attribute would take a string which would then be interpreted as > > the source document markup of an HTML document, much like the above > > This seems very prone to security issues (injection of the closing quote > in the content) to me... The base64 approach is nice in that you can't > shoot yourself in the foot with it. You would only have to escape two characters (" and &, and in fact only the " is needed to be safe). Base64 would indeed be safer. (Right now it's the only option, as I haven't introduced doc='' yet.) But escaping just one character seems like a pretty low bar. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 13 February 2009 23:07:03 UTC