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

[Darin Fisher]

On Tue, Dec 15, 2009 at 11:09 AM, Michael Nordman <michaeln at google.com>wrote:

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

One idea was to leverage adoptNode to make it clear that parenting is being
exchanged.

-Darin



>
>
>
>
>>
>> -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/87819f5d/attachment.html>