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

[Adam Barth]

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.

Thanks,
Adam