[webkit-dev] How loading a frame ought to work

[Darin Adler]

On Oct 13, 2009, at 10:50 AM, Adam Barth wrote:

> * MainResourceLoader. MainResourceLoader inherits from  
> ResourceLoader and receive callbacks from the network stack. It's  
> primary task is to take callbacks from the network stack and route  
> them to the appropriate higher-level APIs. Currently,  
> MainResourceLoader is also concerned with navigation policies, but  
> I'm not sure if that's correct.

I don’t think it’s right that the code to deal with content policy is  
in MainResourceLoader. I think that code belongs in DocumentLoader or  
FrameLoader instead.

> * DocumentLoader.  DocumentLoader is responsible for all the  
> document-specific loading state. For example, the DocumentLoader  
> should know if we've received any data for this document yet and  
> should be in charge of actually stuffing the received data into the  
> Document. (Both of these examples are currently done by FrameLoader.)

That sounds right. Much of the code currently in FrameLoader should go  
into DocumentLoader. Anything about a single document and not about  
transitions between documents should go there.

> * FrameLoader.  FrameLoader is responsible for the frame-level  
> loading state. Essentially, the FrameLoader's job is to determine  
> the disposition of load requests and shepherd DocumentLoaders  
> through the policy / provisional / committed states.

Yes, that sounds good.

> 1) Dispatch.  A load request enters the machine.
>  a) The request is routed to the appropriate frame.
>  b) If the request should generate a fragment scroll, scroll the  
> view and exit the machine.
>  c) Otherwise, create a DocumentLoader to encapsulate the load state  
> for this request.

I don’t know that I would call this “Dispatch” — I suppose the frame  
routing part is good here. I am also not certain that all of the frame  
routing can be done at this point.

> 2) Policy Check. Ask the FrameLoaderClient's policy interface  
> whether the embedder actually wants to go through with the load and  
> wait for a response.

Some policy checks do happen at this point. But note that there are  
other policy checks that occur later. For example, the content policy  
can’t be checked until we receive data from the network.

> 3) Provisional. Once we get the go-ahead from the client, we  
> actually start generating a network request (i.e., create  
> MainResourceLoader). In this phase, we receive redirects and  
> headers, and eventually decide whether to commit the load.

There are content policy checks here.

> A) FrameNavigator. This object would handle the dispatching phase  
> above. The goal of creating this object is to let FrameLoader focus  
> on load requests that will actually result in network / cache traffic.

This seems like a good idea, but I think the boundary will be tricky.  
For example, is detecting when a page load is complete including  
subresources something the frame navigator would be responsible for or  
the loader? What about loading from the back/forward cache as opposed  
to the network?

A list of what functions and data would go in each class might help me  
understand if this refactoring is good.

> B) LoadObserver. Currently ResourceLoader forwards many of the  
> network stack callbacks (e.g., ResourceLoader::didReceiveResponse)  
> to FrameLoader so they can be farmed out to the Web Inspector,  
> ProgressTracker, FrameLoaderClient, and others. The goal of this  
> object is to remove that complexity from FrameLoader.

There is a distinction between resource load client calls and higher  
level load client calls. The resource load client calls are the ones  
that use a request identifier. And these are indeed all about the  
resource loader.

But many other client calls do not involve the resource loader  
directly. If you don’t plan to make the LoadObserver responsible for  
these, then I think it should probably be called the  
ResourceLoadObserver, since it observes the lower level loading of  
resources but not the higher level loading of web pages.

I’m also not entirely sure if “observer” is the right name here, but I  
have nothing better to suggest at this time.

     -- Darin