[webkit-dev] Use of Frame by ResourceHandle
abarth at webkit.org
Sat Sep 11 22:42:08 PDT 2010
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>
>> > 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.
More information about the webkit-dev