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

[Michael Nordman]

On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher <darin at chromium.org> wrote:

> 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.


I hope this use-case can be accommodated, I think this is ultimately the
more generally applicable use-case. Btw, concern for incompatibilities with
existing pages was one reason we came up with a new construct for this
capability (instead of overloading <iframe> or <script>).

How does 'reparentling' work in the absence of the use-case i mentioned?
When the current parent removes the iframe from its DOM, does unload not get
fired, do pending xhr's, and do timers continue run such that they survive
after being added to a new parent's DOM.... how's that work in the magic
iframe scheme?




>
> -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/20091215/b891abf3/attachment.html>