[webkit-dev] Use of Frame by ResourceHandle

[Darin Fisher]

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


It solved/avoided a load of problems/complexity.  What are your concerns?



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

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




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

There always has been such an association.  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.

-Darin



>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100911/f08f5f69/attachment.html>