Hi Dmitry. Two thoughts on this:
(1) If we remove this feature, are Chromium/GMail developers going to re-request the other "shared document" features that this feature subsumed? Or are y'all now convinced that "shared document" is, in general, not a good idea? The reason I ask this is that, given your description, I see some problems with the shared iframe feature, but I still think it's much better than previously proposed alternatives. (2) I think you should share your data with the relevant standards bodies, and suggest a change to the HTML5 spec, if you haven't done so already. I wouldn't want to remove this feature just to add it back later for the sake of spec compliance. Thanks, Geoff 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
