[webkit-dev] Use of Frame by ResourceHandle

[Darin Fisher]

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.)

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.)

-Darin




>
> > I wonder how/if we can migrate that to a bridge, but I am afraid we will
> still
> > need to have some access to Document/Frame/Page.
>
> If we want to be able to use separate network backends for different
> Pages, perhaps we need some sort of PlatformNetworkHandle, which can
> be an opaque object (at least to WebCore) retrieved from the
> FrameLoaderClient.
>
> One of the benefits of removing Frame from the lower levels of the
> loader is that it prevents dependency inversions where objects lower
> down in the dependency chain use the Frame point to talk to objects
> higher up in the dependency chain.  For example, until recently, the
> bytes destined for the main resource made several round-trips through
> the FrameLoader because each object that touched the bytes had a
> pointer to Frame and (for whatever reason) thought FrameLoader ought
> to be involved.
>
> Adam
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100911/a4406ed9/attachment.html>