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 <[email protected]> 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" <[email protected]> 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 >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
