[webkit-dev] SharedScript: next steps and result of offline discussion.

Darin Fisher darin at chromium.org
Mon Dec 14 21:16:43 PST 2009


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 <michaeln at google.com>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 <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
>> 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
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091214/0f5cc656/attachment.html>


More information about the webkit-dev mailing list