On Sat, Sep 11, 2010 at 10:02 PM, Darin Fisher <da...@chromium.org> wrote: > On Sat, Sep 11, 2010 at 9:17 AM, Adam Barth <aba...@webkit.org> wrote: >> On Sat, Sep 11, 2010 at 8:15 AM, Holger Freyther <ze...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
