[webkit-dev] "Magic Iframe" removal proposed

[Adam Barth]

Yeah, normally I would have waited longer, but the patch fixed a crash in
WebKit2 that was making the bots red.  There was a discussion in another
bug (sorry, don't have the link handy) where folks graciously held off
fixing the crash, and I didn't want them to wait any longer than necessary.

Adam
 On Mar 20, 2012 1:31 AM, "Maciej Stachowiak" <mjs at apple.com> wrote:

>
> I'm ok with removing this feature for the reasons you described. I concur
> with others who think we should update the spec. I am also skeptical of
> state sharing features that work via newer, less tested API surface instead
> of latching onto existing features. That seems like a more risky strategy
> since it may be harder to remove such a feature without compat breakage,
> and it's not clear how it makes the security problems even easier.
>
> As a side note, this probably should have had more discussion time before
> being actually committed. If a change is worthy of webkit-dev discussion in
> the first place, then 5 hours between initial webkit-dev post and
> committing the patch is cutting it a bit short. Especially when it is
> outside normal working hours in the time zones where most WebKit
> contributors live. I don't want to harp on this too much, since I don't
> personally disagree with the change, but if anyone does, then they may feel
> that they didn't really get a fair chance to comment.
>
> Regards,
> Maciej
>
>
> On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote:
>
> Hi,
>
> There is a patch posted <https://bugs.webkit.org/show_bug.cgi?id=81590>for removal of the 'magic iframe' feature. This is the ability to move
> 'live' iframe from one page to another w/o unloading it.
> If you have interest or ideas about this feature, please reply.
>
> HISTORY
> This feature was added 2 years ago (bug here<https://bugs.webkit.org/show_bug.cgi?id=32848>).
> It was intended as a shared app context for complex apps that span several
> pages. In case when random set of pages is closed, the surviving iframe
> could be passed between remaining pages and serve as 'app state'.
> This behavior is somewhat described in HTML5 spec<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element>:
> "Removing an iframe from a Document does not cause its browsing context to
> be discarded. Indeed, an iframe's browsing context can survive its original
> parent Document if its iframe is moved to another Document."
> All non-WebKit browsers don't have this and always unload the iframe when
> it is disconnected form the document.
>
> PROBLEMS
> 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.
> As a result, we had quite a few bugs popping up (and fixed).
>
> WHY REMOVE
> This is somewhat obscure feature of the platform. Only a few apps that we
> knew used the feature. Most developers, both app and webkit kind, don't
> even know about it. When new mechanisms/APIs are implemented, a lot of
> objects get associated with Page (WebView) level and they are almost
> 'automatically' broken in case of live iframe transfer because once old
> page closes, it destroys the objects with lifetimes scoped by it. This
> makes it somewhat dangerous and difficult to support. The benefits that it
> gives to the big multi-page applications do not seem to warrant the actual
> complexity of maintaining this feature.
> Other browsers never implemented the feature, siting difficult design due
> to various thorny security issues as well.
>
> This is potentially a compatibility issue for sites that use
> document.adoptNode(iframe) to ensure live transfer of an iframe from one
> page to another.
> In the future, if there will be sufficient need, it is possible to design
> a 'shared module' feature that would explicitly deal with various
> security/lifetime boundaries.
>
> Please let us know what you think.
>
> Thanks,
> Dmitry
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120320/492f7243/attachment.html>