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" <m...@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@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 > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev