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

[George Staikos]

Strongly support your suggested refactoring -- on the condition that  
you clearly document it on the wiki as you go.   This just gets more  
and more complex and I don't think we can risk more refactoring  
resulting in potentially even fewer people having a very clear idea of  
what is happening.

Also I wonder why fragment scroll isn't covered by the policy  
callback.  I haven't had a need to block that before but I can think  
of some cases right now where it might be handy.  I'm not advocating  
bloat without a cause, but perhaps if you're refactoring it we might  
un-special-case it.


On 2009-10-13, at 1:50 PM, Adam Barth wrote:

> I've been studying the various objects related to loading frames, and
> I wanted to get feedback on the below proposal before making a bunch
> of changes.  There seem to be three main objects related to the
> loading state for a frame:
>
> * 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.
>
> * 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.)
>
> * 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.
>
> The FrameLoader goes through the following process:
>
> 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.
>
> 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.
>
> 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.
>
> 4) Committed.  We've decided to actually navigate the frame.
>  a) Detach the old document from the frame.
>  b) Attach the new document to the frame.
>
> In addition to shifting a bunch of the document-specific loading state
> from FrameLoader to DocumentLoader, I think we should create two new
> objects:
>
> 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.
>
> 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.
>
> Let me know if you have any comments or suggestions.

--
George Staikos
Torch Mobile Inc.
http://www.torchmobile.com/