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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
