On Tue, Dec 15, 2009 at 11:09 AM, Michael Nordman <micha...@google.com>wrote:
> > > On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher <da...@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 <micha...@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 <dim...@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@lists.webkit.org >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev