I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded.
-Darin On Mon, Dec 14, 2009 at 2:50 PM, Michael Nordman <[email protected]>wrote: > How does reparenting across in-place frame navigations work in this scheme? > Is a de-parented iframe guaranteed to linger long enough for the new page to > get it by name and re-parent it if desired? > > On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov <[email protected]> wrote: > >> Hi WebKit, >> >> The recent discussion indicated there is a feeling that SharedScript >> functionality can be achieved by other means that do not require adding new >> big APIs: changing iframe a bit (so it's internals survive reparenting into >> another document) and adding single getWindowByName() API. >> >> Ian Hickson proposed this idea noting that nothing in the spec prevents >> iframe from staying alive over the reparenting. Some folks from Google met >> with folks from Apple to discuss and it appears there is a consensus that we >> shall remove initial code for SharedScript and instead implement changes for >> iframe and getWindowByFrame(). This will not cause new API and hopefully >> won't cause compatibility issues since the only scenario that will behave >> differently is reparenting of the iframe between documents that is hopefully >> a rare thing. Perhaps more discussion will be needed to nail details on >> those. >> >> Separately (or related?), we discussed SharedWorkers and the way XHR works >> in them. It seems a good idea to investigate a "shadow document' solution >> (as Chrome does for worker processes) when a dummy document is created and >> used to load resources on behalf of the worker. Also we'll try to fix couple >> of bugs that prevent Workers to be reliable enough. >> >> Thanks a lot to all who chimed in and helped to arrive to a good solution >> to the same issues that SharedScript was trying to solve! :-) >> >> Dmitry Titov >> >> >> >> _______________________________________________ >> 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
