For SharedWorkers, the fallback is to select a document from the document set. It's slightly uglier, though, as I'd need to deal with the case where the user closes the document while we're trying to load via it. Having a dedicated shadow frame would be much simpler. -atw
On Wed, Jun 17, 2009 at 7:03 PM, Dmitry Titov <[email protected]> wrote: > I think there is still little clarity around the appcache behavior (dimich: >>> are you bring over your "shadow frame" concept to webkit?). >>> >> >> I'm wondering about bringing the 'shadow frame' technique to webcore too? >> > > If needs be :-) > > Just to explain what is meant by 'shadow frame' (I'm not sure it was > discussed in webkit-dev beore): to provide access to FrameLoader in Chrome's > Worker process (which loads WebKit but doesn't load any html, just creates a > worker out of JS string), we create a WebView and load it from a (url, > encoding, mimtype, data) source with empty data and the worker's url. This > creates a frame with a an empty document but with a right origin and > encoding. This makes it possible to create a ThreadableLoader (and > underlying DocumentThreadableLoader) w/o aceess to the original worker's > parent. This loader is used to implement XHR and importScripts in Chrome > workers. Oriinally a Darin Fisher's idea, it was implemented as alternative > to rollign out a new frame-less loader. > > Shared workers can use the same approach since they can not forever hold > the ref to the 'creating' document. >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
