Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
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? -Darin On Mon, Dec 14, 2009 at 2:50 PM, Michael Nordman micha...@google.comwrote: 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
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
On Tue, Dec 15, 2009 at 11:09 AM, Michael Nordman micha...@google.comwrote: 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.comwrote: 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.orgwrote: 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
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
On Dec 15, 2009, at 11:09 AM, Michael Nordman 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). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
Saving a subsite of live script and DOM objects across a full page load does not seem useful to me Lots of sites use actual frame navigations to navigate. On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman 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). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman 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). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. This assumes that pages are heavy I believe. The use case was about having most of the load in the shared object and pages being light UI 'frames'. This would allow to use regular URLs and history management of the browser directly. Moving most of the code and parking DOM (like editor chrome) in a shared object could enable very lightweight pages. It sounds a bit theoretical now but the hope was that it brings interesting way of building apps in a way which could be better and perhaps simpler then building heavy non-navigatable ajax pages that have to generate content and use onbeforeunload to warn user that moving away is a bad idea :-) Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
On Dec 15, 2009, at 12:38 PM, Dmitry Titov wrote: On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman 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). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. This assumes that pages are heavy I believe. The use case was about having most of the load in the shared object and pages being light UI 'frames'. This would allow to use regular URLs and history management of the browser directly. Moving most of the code and parking DOM (like editor chrome) in a shared object could enable very lightweight pages. Regardless of how light the page is, a page transition is likely to be much more disruptive to user flow, particularly if the new page has to be loaded over the network and the operation takes a long time. It sounds a bit theoretical now but the hope was that it brings interesting way of building apps in a way which could be better and perhaps simpler then building heavy non-navigatable ajax pages that have to generate content and use onbeforeunload to warn user that moving away is a bad idea :-) I think you bundled up a lot of concepts in there that are not intrinsically tied together. You can have a page self-load new markup as HTML, insert it into itself, and update the URL and history entries with pushState, without having to do a full page load. Having no page load and replacing only the things you want to change seems better to me than having a full page load but somehow trying to save code and data across it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
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
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
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 micha...@google.comwrote: 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
[webkit-dev] SharedScript: next steps and result of offline discussion.
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
