[webkit-dev] Use of Frame by ResourceHandle

David Levin levin at chromium.org
Sun Sep 12 12:43:19 PDT 2010


On Sun, Sep 12, 2010 at 12:37 PM, Adam Barth <abarth at webkit.org> wrote:

> On Sun, Sep 12, 2010 at 12:33 PM, David Levin <levin at chromium.org> wrote:
> > On Sat, Sep 11, 2010 at 11:07 PM, Adam Barth <abarth at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100912/d9648f51/attachment.html>


More information about the webkit-dev mailing list