[webkit-dev] "Magic Iframe" removal proposed

[Aaron Boodman]

I actually do know of at least one WebKit-only application under
development at Google that may be using this feature (I recently
suggested it to them).

Oh well.

- a

On Tue, Mar 20, 2012 at 8:07 AM, Adam Barth <abarth at webkit.org> wrote:
> 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 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). 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: "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
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>