[webkit-dev] Use of Frame by ResourceHandle

Mon Sep 13 22:21:32 PDT 2010

I agree that NetworkingContext is cleaner than a direct Frame association.
 I'm concerned though about the idea of network requests that are not
associated with a Page.  Associating network requests with a Page is
important so that you know how to show UI (auth prompt, cookie prompt, ssl
error prompt, etc.) associated with network requests.  It is nice to know
the Page context so that those dialogs can be scoped to a tab, for example.

Maybe a dummy Frame is not the best answer in all cases.  It is not obvious
to me that it is a bad solution for shared workers though.

Unfortunately, that solution is buggy.  Suppose a use createDocument

to make an XML document in one Frame and then move the JavaScript

object to another Frame and close the first one.  Now XSLT magically

stops working because the "owner document" don't have a Frame anymore.

> Adam

Hmm, we can look at that case in two ways:  1) at the point that the
navigation starts, we can use the associated frame as the context since we
only really need context while starting a request, or 2) perhaps the
NetworkingContext can be used to make the frame association indirect enough
that it can be swapped at runtime.

-Darin

On Sat, Sep 11, 2010 at 11:33 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> I like Adam's thinking on this. ResourceHandle depending on Frame, even
> indirectly, is something of a layering violation. It makes more sense to
> factor out the bits that it does need, a la NetworkContext. Using client
> methods to make an association externally seems ok too, but poses more risk
> that someone will fail to call the relevant delegate method.
>
> I have to agree that the way SVG-in-<img> was done, in particular, has
> ended up causing heaps of trouble even though it was an expedient choice to
> get the feature working quickly. It would be better if more things could be
> decoupled from Frame so we can get out of the business of making fake ones.
>
> Regards,
> Maciej
>
> On Sep 11, 2010, at 11:28 PM, Darin Fisher wrote:
>
> On Sat, Sep 11, 2010 at 11:07 PM, Adam Barth <abarth at webkit.org> wrote:
>
>> On Sat, Sep 11, 2010 at 10:52 PM, Darin Fisher <darin at chromium.org>
>> wrote:
>> > 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:
>> >> > 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?
>>
>> Having fake versions of objects add complexity to all the code that
>> expects to talk to real versions of those objects.
>
>
> This sounds like trading off one form of complexity for another.  Maybe the
> answer is something like a base class.
>
>
>
>>  For example,
>> SVG-in-<img> creates a ton of fake objects and has been the source of
>> a lot of bugs (including security bugs).  It seems like having a
>> notion of a networking context makes more sense than pretending shared
>> workers are associated with a rectangular region of a screen
>> somewhere.
>>
>> >>  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.
>>
>> What happens when code later in the loading cycle assumes this Frame
>> is still present?  To avoid exploding, that code needs to understand
>> that in this tiny corner of the loader, life is different, which is a
>> big testing and maintenance burden.
>>
>
> I agree that those later steps need not have a frame association.  I was
> referring to the frame association given to a ResourceRequest (via
> FrameLoaderClient::dispatchWillSendRequest) or via the explicit Frame
> pointer that was once passed to ResourceHandle.
>
>
>
>>
>> > 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?
>>
>> I don't think so.  PingLoader talks directly to ResourceHandle.
>> PingLoader knows about the Frame, but it looks like it only uses it to
>> determine the outgoing referrer, to
>> addExtraFieldsToSubresourceRequest, and to grab the networking
>> context.
>>
>
>
> Hmm... it seems like a bug that it doesn't call dispatchWillSendRequest.
>  That does some important work that should apply to all network requests.
>
> Take a look at FrameLoaderClientImpl::dispatchWillSendRequest under
> WebKit/chromium/src/.  It calls setFirstPartyForCookies in one case!
>
>
>
>>
>> > 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.)
>>
>> There are are lots of ways to get a Frameless document.  For example,
>> JavaScript can call document.implementation.createDocument.  Also, the
>> DOMParser will given you a document.  XMLHttpRequest will give you
>> one.  You can get one by having an XSLT.  The PageCache has some.
>>
>> There was a patch that someone was pushing at some point to chain
>> these documents back to a "master" document that has a frame.  That's
>> certainly one approach, but I don't think it should be necessary.
>>
>
> That's the solution I would have expected.  It fits more naturally with our
> system.
>
>
>
>>
>> >> 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.
>>
>> Right, and there are bugs we've never been able to fix because of that
>> coupling.
>>
>> > 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.
>>
>> Here's an example bug from 2006 that's marked Critical:
>>
>> https://bugs.webkit.org/show_bug.cgi?id=10313
>>
>> The patch attached to that bug is a giant workaround for the fact that
>> the loader is too dependent on Frame.
>>
>> Adam
>>
>
>
> I see.  It seems like it is always possible to find an associated Frame.  I
> agree that it would be simpler if we didn't have to.  I just worry that that
> isn't an option.
>
> One thing to consider:  It is important for network requests to have an
> associated browser tab so that any associated UI (auth prompts, security
> warning dialogs, cookie prompts, etc.) can be anchored properly.  It turns
> out that the only context Chromium really needs to associate with network
> requests is an identifier that corresponds to the Page (routing ID).  You
> can see that ResourceRequest (in the Chromium port) has such a member
> variable named m_requestorID.  This is used to stash the routing ID, which
> Chromium uses inside its implementation of ResourceHandle (actually in the
> implementation of WebKit::WebURLLoader).
>
> -Darin
>
> _______________________________________________
> 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/20100913/de68d7f9/attachment.html>