[webkit-dev] document()->frame()->script()->globalObject()

[Maciej Stachowiak]

On Jul 24, 2009, at 2:18 PM, Darin Adler wrote:

> On Jul 24, 2009, at 11:05 AM, Adam Barth wrote:
>
>> Do you have specific areas you're concerned about that we can be on  
>> the lookout for?
>
> I tried to think this through, but only had a few minutes free:
>
> A minor concern is that Frame has a constellation of helper classes  
> to help keep it simple, including ScriptController, but Document  
> does not, so this change will add more non-“model” things to the  
> Document header, muddying our architecture.

I think that long-term we need to have a class to represent all the  
state of a Frame that changes whenever the document changes. Right now  
the closest we have to that is DocumentLoader, but it doesn't really  
hold all of the per-document state, some needs to be swapped out  
separately.

I could imagine three plausible designs:

1) Document becomes the master class that owns everything which needs  
to change when the document changes, including the inner window and  
the DocumentLoader.

2) DocumentLoader becomes the master class that owns everything, and  
the relevant fields are moved from other classes, such as Frame, to  
DocumentLoader. Document gets a backpointer to DocumentLoader but  
otherwise can be mostly limited to its primary role of implementing  
the DOM document.

3) A new class becomes the master class and owns all three of  
DocumentLoader, Document and the inner window.

I personally like #2 or #3 better than #1, I think Document itself  
will be easier to understand if it remains primarily an implementation  
of the DOM Document interface. I think #2 is plausible and maybe a  
good idea, since a lot of the trickiness of when to swap documents  
relates to loading.

I think that even though this is the right long-term architectural  
direction, we should be very careful and do changes towards this  
design in steps. The reason is that it ties into document transition  
and central object lifetime, which are both areas that are somewhat  
fragile to compatibility, robustness and security bugs.

So probably I wouldn't make too much of this redesign a prerequisite  
for other changes.

Regards,
Maciej

>
> There are dormant documents that are in the back/forward cache, and  
> it’s important that we not do more work in these. At the moment,  
> it’s possible that the fact that frame() is 0 is how certain  
> operations are disabled in such things.
>
> The same type of issue could apply to documents that are not in the  
> back/forward cache, and no longer in the frame, but still alive for  
> some reason.
>
> Creation and teardown seem like the trickiest areas. The timing of  
> creation of the global object vs. the document might end up being  
> different than today.
>
> The timing issues are likely to be different per-platform because of  
> the excessive complexity of the FrameLoaderClient, so we would want  
> to make the changes in small steps with a lot of testing.
>
>    -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev