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
