On Sun, Sep 12, 2010 at 12:37 PM, Adam Barth <aba...@webkit.org> wrote:
> On Sun, Sep 12, 2010 at 12:33 PM, David Levin <le...@chromium.org> wrote: > > On Sat, Sep 11, 2010 at 11:07 PM, Adam Barth <aba...@webkit.org> wrote: > >> Having fake versions of objects add complexity to all the code that > >> expects to talk to real versions of those objects. For example, > >> SVG-in-<img> creates a ton of fake objects and has been the source of > >> a lot of bugs (including security bugs). It seems like having a > >> notion of a networking context makes more sense than pretending shared > >> workers are associated with a rectangular region of a screen > >> somewhere. > > > > A clarification: > > The "fake" frame only happens in Chromium. It is due to the fact that > > workers are in a different process from the real frame. > > In !chromium platforms, the real frame is used to send the request for > both > > dedicated and shared workers. (It is a bit unfortunate in the shared > worker > > case because closing that frame will kill the xhr request but the > reasoning > > has been that code should be resilient to xhr failures as they can happen > > for a number of reasons.) > > Once the Frame is gone, XHR stops functioning for the SharedWorker > permanently? That sounds like a bug that should be fixed. > Nope only for that xhr request. Basically, the code picks a frame to send out the request through everytime that a request is done. If that frame goes away, then the request will fail but another request will go through a different frame. One idea of how to fix this is to use a fake frame for sending out the request from the shared worker :). The other idea is that code should be resilient to occasional xhr failures. dave > > Adam >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev