[webkit-dev] FrameLoader cleanup

[Brady Eidson]

Every time we've made changes to the loading architecture, be it the  
original Frame class, the original Mac-only WebKit loaders, or  
significant changes to FrameLoader itself, we've caused numerous  
regressions - both subtle and extreme - that take forever to weed  
out.  This is a primary reason that this oft-requested, much-needed  
undertaking hasn't gotten serious traction.

Testing loading behavior was a later addition to DumpRenderTree (which  
originally only dumped the render tree, as difficult as it might be to  
imagine), and has languished behind the volume and scope of changes  
that have occurred in the loaders.

I think before any actual behavioral changes are made, someone needs  
to actually put in the time and effort to give DRT a substantial  
overhaul in its ability to regression test the many subtle processes  
the loader undertakes.

~Brady

On Sep 25, 2009, at 1:46 PM, Adam Barth wrote:

> Every time I look at FrameLoader, it makes me cry.  I think I have
> some time in my schedule to clean it up a bit.  I haven't studied the
> code in detail, but my plan is as follows:
>
> 1) Separation of concerns.  FrameLoader has its fingers in a bunch of
> different pies.  In this phase, I'll try to break FrameLoader up into
> a bunch of smaller objects that are in charge of managing different
> pots of state.
>
> 2) Explicit state machines.  FrameLoader holds a lot of state as bool
> members.  In this phase, I'll try to convert these flags into an
> explicit state machine with clear state graph.
>
> 3) API surface reduction.  FrameLoader has a large number of public
> entry points.  In this phase, I'll reduce the API surface of the core
> state machines to it's more clear where clients can enter the machine.
>
> This is a big task, and I'm going to try to do it incrementally.  If
> you have thoughts or would like input, let me know.
>
> Thanks,
> Adam
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev