[webkit-dev] SharedScript: next steps and result of offline discussion.
michaeln at google.com
Mon Dec 14 14:50:04 PST 2009
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 <dimich at chromium.org> 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
> 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
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev