[webkit-dev] Use of Frame by ResourceHandle

[Adam Barth]

On Sat, Sep 11, 2010 at 10:02 PM, Darin Fisher <darin at chromium.org> wrote:
> On Sat, Sep 11, 2010 at 9:17 AM, Adam Barth <abarth at webkit.org> wrote:
>> On Sat, Sep 11, 2010 at 8:15 AM, Holger Freyther <zecke at selfish.org>
>> wrote:
>> > On 09/11/2010 05:57 PM, Adam Barth wrote:
>> >> Do we still believe this FIXME is accurate?  If so, I have some time
>> >> next week to look at removing the dependency.  There's a patch that
>> >> either recently landed or is about to land that furthers the use of
>> >> Frame by ResourceHandle, so I wanted to check with folks more broadly
>> >> about whether this is the right direction.  (Note that I haven't
>> >> studied the code yet, so I'm not sure what would be required to remove
>> >> the dependency.)
>> >
>> > I'am afraid QtWebKit is using that for a layering violation. Each
>> > QWebPage
>> > (wrapper around WebCore::Page + FrameView) can have a separate network
>> > engine
>> > (QNetworkAccessManager) and we go from WebCore::Frame to WebKit to find
>> > out
>> > which engine to use.
>>
>> How does Qt implement XMLHttpRequest from WebWorkers?  Workers don't
>> have a Frame to supply.  SharedWorkers are even trickier...
>
> 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.  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).

> By the way, the Chromium port once used the Frame pointer that was passed to
> ResourceHandle.  This was back before we opensourced.  At that time,
> loadResourceSynchronously did not take a Frame pointer.  When, I suggested
> adding that Frame pointer (see
> https://bugs.webkit.org/show_bug.cgi?id=14106), I was corrected (by Maciej
> on #webkit IIRC) on the grounds that it propagated a layering violation.
>  His suggested workaround was to leverage
> FrameLoaderClient::dispatchWillSendRequest, and that worked great.  It
> allowed us to tag the ResourceRequest with information that was Frame
> specific before the ResourceHandle was created.
> I wonder why NetworkingContext is necessary given
> FrameLoaderClient::dispatchWillSendRequest.  (I also wonder
> why https://bugs.webkit.org/show_bug.cgi?id=16588 wasn't resolved WONTFIX
> like bug 14106.)

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.

I need to study NetworkContext more closely, but it seems like it
would be useful for remembering which network backend is supposed to
service a given ResourceHandle.

Adam