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

[whatwg] keepalive attribute on iframe

From: Ojan Vafai <ojan@chromium.org>
Date: Thu, 12 Apr 2012 15:49:47 -0700
Message-ID: <CANMdWTuBfYWAgsvMW_n_Q0OMtA4a1FD_1UFxJ2yzWBNTev+vWA@mail.gmail.com>
Quoting from the webkit-dev email killing this feature for cross-document
iframe loads:
"We did have quite a few issues with this mechanism. The root of the
problem seems to be that traditionally, multiple 'permissions' and 'live
objects' are associated with a top-level page, or a top frame of some kind,
instead of being associated with each Frame. Even HTML specifications
often formulate the scope of things like permissions in terms of a page -
for example, geo permissions are computed based on the origin of the page.
When an iframe is transferred from one page to another, it may enter a
different set of permissions while already performing operations
authorized before. Association with the top-level page is also used to
determine which one should show modal UI for HTTP Auth, per-origin
permissions, or certificate issues for example."

On Thu, Apr 12, 2012 at 12:45 PM, Adam Barth <w3c at adambarth.com> wrote:

> One path we saw in a couple exploits was to trick the code for moving
> frames between documents into keeping the frame alive outside of the
> DOM.  Having a live frame outside of the DOM caused all kinds of
> madness.
>
> The underlying problem is that it's a strange, uncommon situation that
> affects many code paths.  When folks write those code paths, they
> don't think about the live-frame-outside-the-DOM case and that
> situation doesn't get hardly any testing.
>

I feel like these are just implementation problems we need to address. We
can't keep pushing more and more core functionality into iframes and not
even be able to move them around in the DOM. It's OK to me, at least in the
short term, if we disallow keepalive for cross-document moves given the
problems WebKit had.

Adam
>
>
> On Thu, Apr 12, 2012 at 12:41 PM, Ojan Vafai <ojan at chromium.org> wrote:
> > I thought the issue here was with moving iframes across documents, not
> with
> > keeping disconnected iframes alive. I'll ping the engineers working on
> this
> > and see if I can get more information.
> >
> > On Thu, Apr 12, 2012 at 12:37 PM, Adam Barth <w3c at adambarth.com> wrote:
> >>
> >> We just got finished removing this feature from WebKit because it
> >> caused many security and stability problems.  It turns out that
> >> there's a lot of code in browsers that can't cope with a disconnected
> >> iframe being alive.
> >>
> >> Adam
> >>
> >>
> >> On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai <ojan at chromium.org> wrote:
> >> > We should add a keepalive attribute to iframes that prevents iframes
> >> > from
> >> > being unloaded/reloaded when removed from or appended to a document.
> >> > Similarly, a disconnected iframe with keepalive should load. If the
> >> > keepalive attribute is removed from a disconnected iframe, then it
> >> > should
> >> > unload.
> >> >
> >> > I'm not terribly happy with the name 'keepalive', but I can't think of
> >> > anything better at the moment.
> >> >
> >> > As iframes increasingly become the standard way of achieving certain
> >> > tasks
> >> > (e.g. sandboxing), it's increasingly important to be able to move them
> >> > around in the DOM. Right now, to achieve this sort of keepalive
> >> > behavior,
> >> > you have to keep the iframe always appended to the document and
> position
> >> > it
> >> > absolutely as the document changes.
> >> >
> >> > Ojan
> >
> >
>
Received on Thursday, 12 April 2012 15:49:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:07 GMT