Boris Zbarsky to dev-platform

show details 4:16 PM (1 hour ago)

On 4/14/11 10:00 AM, Henri Sivonen wrote:

In the spec, there a four main objects involved in a document load and
navigation:
1) browsing context
2) WindowProxy (aka. outer window)
3) Window (aka. inner window)
4) Document

Each browsing context has a WindowProxy. Each Document has a Window.

Is that last bit true for documents returned via XMLHttpRequest, say?

An nsDocShell corresponds exactly to a browsing context, right?

Yes.

Does an nsIContentViewer correspond exactly to the spec's (inner) Window for the
purpose of the loading machinery even though the JS object corresponding
to Window is an nsGlobalWindow marked as being of the inner flavor?

An nsIContentViewer corresponds in lifetime to a document, sort of (some documents have no associated content viewer, and documents in general can outlive their content viewer if someone just holds on to them, but for purposes of loading machinery the correspondence is correct I think).

In the spec, a Window has a 1-to-1 correspondence to a Document except
when the Window's document changes from the initial about:blank into
another Document. Does the same hold for nsIContentViewer?

No.

Does it also get coupled 1-to-1 to an nsIDocument except for the initial about:blank?

No. The initial about:blank and the document that actually loads have different content viewers.

Have I understood correctly that an nsIContentViewer is always also an
nsIDocumentViewer and always an DocumentViewerImpl?

Yes, in our implementation. Modulo binary extensions, of course.

(What's the point of
having separate nsIContentViewer and nsIDocumentViewer interfaces?)

I believe at one point (before my time, I think) there was a plan to have non-document viewers (e.g. for full-page images, full-page plugins, whatever). I don't believe there is such a plan anymore. Certainly not on my part!