[webkit-dev] Use of Frame by ResourceHandle

[Adam Barth]

On Sun, Sep 12, 2010 at 12:43 PM, David Levin <levin at chromium.org> wrote:
> 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.

I see.  That doesn't seem that horrible.  Another approach is to have
a concept like a NetworkingContext that isn't tied to a Frame.  The
embedder could then assign a routing ID to the networking context and
we wouldn't need to have a fake Frame.

Adam