[webkit-dev] How loading a frame ought to work
staikos at kde.org
Tue Oct 13 15:00:30 PDT 2009
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
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
> * 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
> 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
> 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.
Torch Mobile Inc.
More information about the webkit-dev