[webkit-dev] FrameLoader cleanup
beidson at apple.com
Fri Sep 25 15:53:22 PDT 2009
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.
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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev