[webkit-dev] Use of Frame by ResourceHandle

[Adam Barth]

On Sat, Sep 11, 2010 at 10:52 PM, Darin Fisher <darin at chromium.org> wrote:
> On Sat, Sep 11, 2010 at 10:42 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Sat, Sep 11, 2010 at 10:02 PM, Darin Fisher <darin at chromium.org> wrote:
>> > I don't understand.  WebWorkers use ThreadableLoader, which routes the
>> > network request back to the main thread where there is an associated
>> > Frame.
>> >  (SharedWorkers have a dummy frame associated with them.)
>>
>> See.  The dummy frame sounds unfortunate.
>
> It solved/avoided a load of problems/complexity.  What are your concerns?

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.

>>  In general, there are also
>> situations on the main thread where we'd like to perform a load
>> without a Frame.  I'd have to look at the details, but there are
>> long-standing bugs about applying XSLT to Frame-less documents.  Also,
>> the PingLoader doesn't have a Frame available (it's job is to make
>> image requests that outlive the Frame).
>
> PingLoader has an associated Frame when it kicks off the load.  That is the
> critical time when Frame association is usually needed.

What happens when code later in the loading cycle assumes this Frame
is still present?  To avoid exploding, that code needs to understand
that in this tiny corner of the loader, life is different, which is a
big testing and maintenance burden.

> For example, you
> cannot load any network requests in Chromium unless you know what Page (you
> need to know the routing ID of the tab) is requesting the resource.  I
> assume PingLoader still generates the
> FrameLoaderClient::dispatchWillSendRequest notification, right?

I don't think so.  PingLoader talks directly to ResourceHandle.
PingLoader knows about the Frame, but it looks like it only uses it to
determine the outgoing referrer, to
addExtraFieldsToSubresourceRequest, and to grab the networking
context.

> How do you get a frame-less document?  Via XMLHttpRequest.responseXML?
> Perhaps it could use the Frame of the script execution context?  (Which
> script execution context is a good question.)

There are are lots of ways to get a Frameless document.  For example,
JavaScript can call document.implementation.createDocument.  Also, the
DOMParser will given you a document.  XMLHttpRequest will give you
one.  You can get one by having an XSLT.  The PageCache has some.

There was a patch that someone was pushing at some point to chain
these documents back to a "master" document that has a frame.  That's
certainly one approach, but I don't think it should be necessary.

>> In general, there is no necessary connection between network requests
>> made by WebCore and Frames.  Techniques that aim to associate a frame
>> with every network request won't work in some cases because such a
>> Frame might not exist.
>
> There always has been such an association.

Right, and there are bugs we've never been able to fix because of that coupling.

> I would like to understand the
> concerns better.  I guess it means that I need to understand the frame-less
> document issue and why you think having a dummy frame associated with shared
> workers is a problem.

Here's an example bug from 2006 that's marked Critical:

https://bugs.webkit.org/show_bug.cgi?id=10313

The patch attached to that bug is a giant workaround for the fact that
the loader is too dependent on Frame.

Adam