W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

Re: [whatwg] <iframe srcdoc> definition not compatible with existing user-agent user interfaces

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 4 Apr 2013 22:15:16 -0700
Message-ID: <CAAWBYDDpY-kQRn87Eizx0h+QFcVczQbhc_cnkvn-tRngSRu-qA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg <whatwg@lists.whatwg.org>
On Thu, Apr 4, 2013 at 2:12 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> The way <iframe srcdoc> is defined, the document URI does not in any way
> encode the document contents.
>
> Unfortunately, that breaks user-agent and extension features like "open
> frame in new window", "show only this frame", "open frame in new tab", etc.
>
> I just tried this in the two UAs I have that implement such features, and
> Chrome simply doesn't have such options in its default UI, while in Safari
> those context menu options are in fact just completely broken.
>
> This seems fairly undesirable.  Is there a reason we don't want a URI which
> _will_ encode the source in some way so as to avoid breaking basic UI like
> this?

Are you asking to switch back to data urls instead of srcdoc, or are
you asking for a way to generate an equivalent data url from the
contents?

The former was addressed during the design of srcdoc - the escaping
requirements of data urls are non-trivial, and given that this is
supposed to be an easy security measure, any difficulty in escaping
means people will fail and get security escapes.

If it's the latter, I think that makes sense.

~TJ
Received on Friday, 5 April 2013 05:16:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC