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@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
