[webkit-dev] Possible rule of thumb for FrameLoader vs. DocumentLoader code

[Adam Barth]

That sounds pretty much exactly in line with how I'd like to see this
code evolve.  It seems like FrameLoader should hold the following
state:

1) The various DocumentLoaders (provisional, policy, and committed).
2) A state machine concerning the lifecycle of navigating a frame
(displaying initial document, navigation pending, committed, client
redirects, etc).
3) Various subcontrollers related to navigation (e.g.,
HistoryController, NavigationScheduler).  We can move these elsewhere
if you think they'd be better somewhere else (e.g., on Frame).

In terms of what's in FrameLoader now that I think should move out,
we're getting pretty close.  These are what's left on my list:

1) Functions relating to mixed content.  These should move off to some
smaller object responsible for understanding mixed content.
2) Functions related to submitting forms.  These should move off to be
another subcontroller, like the NavigationScheduler.  They're really
about getting form submissions ready and finding the right Frame to
navigate, not about actually doing the navigation.
3) Various functions and state related to firing Document lifecycle
DOM events (e.g., the load event, the unload event).  These seem more
like they should be DoucmentLoader's job because they relate to a
specific document, not to the transition between documents.

Aside from the normal navigation case, there's also all the special
cases for the PageCache.  It's sightly unclear to me what of that
knowledge should be in FrameLoader and what should be in
PageCache-specific objects.

Finally, there's a lot of redundancy in terms of kicking off and
stopping navigations.  I'd like to clean that up as well because today
it's very unclear when various functions are safe to call and why you
might choose to call one instead of another.  I think we were somewhat
successful in doing that for NavigationScheduler (although it's
slightly unclear what the difference is between scheduleRedirect and
scheduleLocationChange).

Adam


On Fri, Jun 24, 2011 at 4:57 PM, Darin Adler <darin at apple.com> wrote:
> I have an idea for a rule of thumb for what code should be in FrameLoader and what should go in DocumentLoader.
>
> I’d suggest that we leave code in frame loader that relates to switching from one document to the next. Starting a navigation to a new location, creating a document loader for the new location, that sort of thing.
>
> And we move code from frame loader to document loader that relates to loading once a document loader exists. Pretty much anything you do in the context of a document that’s already loaded would be in document loader. My brief perusal of the current code in frame loader gives me the impression that this would be more than 50% of the code still in there.
>
> My hope is that we’d move both functions and data based on this rule of thumb. It may be tricky to do this without breaking anything, some things may currently work for strange or unintentional reasons and rely on state that outlasts the document loader.
>
> Thoughts on this?
>
>    -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>