Multiple presshells
Aaron Leventhal
Is it possible to have more than one? If not, shouldn't we
clear this up?
Also, correct me if I'm wrong, but we basically have a 1 to
1 relationship between these objects:
docshell, presshell, prescontext, document, domwindow,
widget, docshell and contentviewer
These are created for elements such as:
<browser>, <iframe>, <frame>, <editor>, etc.
Correct or no? Do we have docs on how this works including
the ownership model? What changes are planned for the future?
- Aaron
Peter Kasting
> Why do our interfaces allow for multiple presshells?
>
> Is it possible to have more than one? If not, shouldn't we clear this up?
If I recall bryner's comments accurately, we can have two: the 0th
presshell, which is the "normal" one, and the 1st, which is the
"printing" presshell.
> Do we have docs on how this works including the ownership
> model?
I've seen a couple graphical representations of this, but I can't
remember where they are at the moment. darin or bryner should know, I
think.
PK
L. David Baron
> Why do our interfaces allow for multiple presshells?
We support multiple presentations of the same document. We
currently use this for printing. We should probably be using it for
print preview if print preview weren't a total hack (we actually
might be). In theory we could also use it for things like multiple
views in editors, although nobody's done that.
One school of thought says we should remove this and switch printing
to clone the document. The other says that this doesn't hurt us
much and can be quite useful.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Boris Zbarsky
> Why do our interfaces allow for multiple presshells?
I think dbaron handled this already.
> Also, correct me if I'm wrong, but we basically have a 1 to 1
> relationship between these objects:
> docshell, presshell, prescontext, document, domwindow, widget, docshell
> and contentviewer
You're wrong. :)
There's a 1-1 relationship between docshell and docshell, sure. There is a 1-1
relationship between docshell and outer domwindow. There is a 1-1 relationship
between presshell and prescontext, except during setup and teardown.
There is a 1-1 relationship between inner domwindow and document, except that
some documents don't have inner domwindows (though we might change that) and
that some inner domwindows might no longer have documents even though they are
still alive.
There is a 1-many relationship between outer domwindows and inner domwindows, in
general, though one can only get at the "current" inner domwindow from the outer
domwindow.
There is a 1-1 relationship between content viewer and presshell, except a
document viewer may not have a presshell, and which exact presshell it has can
change at any time.
There is a 1-1 relationship between document and content viewer, except some
documents may not have content viewers.
There is a 1-many relationship between docshell and content viewer in general.
The only time many > 1 is during paint suppression.
I don't know how widgets got in here. We have all sorts of widgets not related
to any of this stuff. As far as docshells go, each docshell has a widget inside
it and many docshells have a widget immediately outside them. This state of
affairs is not expected to persist into Gecko 1.9 -- by that point there will
hopefully be a single widget for the root docshell in the docshell hierarchy and
that's it.
> These are created for elements such as:
> <browser>, <iframe>, <frame>, <editor>, etc.
And <object>, yeah.
> Correct or no? Do we have docs on how this works including the ownership
> model? What changes are planned for the future?
We do not have good docs, no. At some point I tried setting up an ownership
model map of "document and window level objects" while trying to review bfcache.
I'll paste it in at the end of the mail. It's probably pretty out of date,
being about 16 months old, especially with splitwindow happening in between.
And I don't think I ever completed it... For example, the nsDocumentViewer [art
is empty. But I actually think it was out of date within a month or two of me
creating it... which is the usual problem with trying to document this stuff.
:( That said, if someone wants to document this, it's a start.
As for changes, I think I mentioned a few above. I also still think we should
merge presshell and prescontext into a single class. I believe roc wants to
eliminate view manager altogether. Past that, I think we should think about how
we can simplify this mess.
-Boris
---------------------------------------------------------------------------------
Ownership model (out of date):
Key:
+: strong ref
-: weak ref raw ptr
=: nsWeakPtr ref
*: owner (new/delete)
#: non-pointer member
Refcounted objects have a '|' before the object name in the list. In general,
any weak ref held by a refcounted object that is not explicitly cleared is a
crash waiting to happen.
Note that this list does not include parent/child pointers amongst documents,
docshells, viewmanagers, etc.
I've left out a lot of things that are in a 1-1 relationship with just the
document (and which correctly drop weak refs when it goes away) for clarity.
------------------------------------------------------------
Long-lived objects (across document loads):
------------------------------------------------------------
|nsWebShell:
+nsLoadGroup -- mLoadGroup (set in nsDocLoader::Init, never cleared)
+DocumentViewerImpl -- mContentViewer (set in nsDocShell::SetupNewViewer [via
Embed],
released in nsDocShell::Destroy)
+nsDeviceContext -- mDeviceContext (set in nsDocShellEnsureDeviceContext,
cleared in SetParentWidget [called via nsIBaseWindow setup stuff])
XXX this should clear any time mParentWidget changes! But device contexts
are refcounted, so we still have problems. Basically, the device context
needs to hold a strong ref to the widget it's created for or something
like that. Changes to the parent widget here should wipe all
presentations, I guess....
+nsGlobalWindow -- mScriptGlobal (set in nsDocShell::EnsureScriptEnvironment,
released in nsDocShell::Destroy). XXX fix ordering dependency with
SetChromeEventHandler here, somehow!
+nsGlobalWindow -- via mSecurityUI (set and cleared via scriptable interface)
+nsCommandManager -- mCommandManager (not the same one as in nsHTMLDocument,
set in EnsureCommandManager, released in ~nsWebShell)
|nsGlobalWindow:
+nsDocument -- mDocument (set in SetNewDocument, released in SetNewDocument
and ~nsGlobalWindow)
+nsGlobalWindow -- strong ref to self via mScriptContext. (Set when the
script context is created, cleared in SetDocShell, ReallyCloseWindow.)
-nsWebShell -- mGlobalObjectOwner (set and cleared in SetGlobalObjectOwner
[via nsDocShell::EnsureScriptEnvironment and
nsDocShell::Destroy respectively])
-nsWebShell -- mDocShell (set and cleared in SetDocShell
[via nsDocShell::EnsureScriptEnvironment and
nsDocShell::Destroy respectively])
XXXbz why not just QI this off mGlobalObjectOwner?
|nsCommandManager:
-nsGlobalWindow -- mWindow (set in Init, never cleared; XXX this is buggy)
|nsLoadGroup:
=nsWebShell (in our case) -- mCallbacks (set in SetNotificationCallbacks)
=nsWebShell/nsDocLoader -- mObserver (set in SetGroupObserver)
------------------------------------------------------------
Per-document objects:
------------------------------------------------------------
|nsDocument:
=nsLoadGroup -- mDocumentLoadGroup (set in ResetToURI, never cleared)
=nsWebShell -- mDocumentContainer (set in SetContainer
[via nsDocShell::CreateAboutBlankContentViewer or
DocumentViewerImpl::SetDOMDocument],
never cleared)
-PresShell -- mPresShells (set in nsDocument::doCreateShell,
cleared in DeleteShell [via PresShell::Destroy]
+nsGlobalWindow -- mScriptGlobalObject (set and released in
SetScriptGlobalObject)
-PresShell -- mObservers (cleared via PresShell::EndObservingDocument,
mostly called from content viewer code, right before calling
PresShell::Destroy; XXX maybe just call it from PresShell::Destroy?)
|nsHTMLDocument (additional to nsDocument):
+nsParser -- mParser (set in StartDocumentLoad, released in EndLoad)
+nsCommandManager -- mMidasCommandManager (set in GetMidasCommandManager,
released in ~nsHTMLDocument)
|nsXMLDocument (additional to nsDocument):
+nsGlobalWindow -- via mScriptContext (set in Load, never released, effectively)
|nsContentSink:
+nsDocument -- mDocument (set in Init, released in ~nsContentSink)
+nsParser -- mParser (set in SetParser [via nsParser::SetContentSink],
released in DidBuildModel
+nsWebShell -- mDocShell (set in Init, released in ~nsContentSink)
|nsXULContentSink:
=nsDocument -- mDocument (set in Init, cleared in DidBuildModel)
+nsParser -- mParser (set in SetParser [via nsParser::SetContentSink],
released in DidBuildModel)
|nsParser:
+nsContentSink/nsXULContentSink -- mSink (set in SetContentSink,
released in ~nsParser)
------------------------------------------------------------
Mutant not really per-presentation, but sorta objects:
------------------------------------------------------------
|nsDocumentViewer:
|nsDocViewerSelectionListener:
-DocumentViewerImpl -- mDocViewer (set in Init, never cleared XXX this can
lead to crashes)
------------------------------------------------------------
Per-presentation objects:
------------------------------------------------------------
|PresShell:
+nsDocument -- mDocument (set in Init, released ~PresShell)
+nsPresContext -- mPresContext (set in Init, released ~PresShell)
*nsStyleSet -- mStyleSet (set in Init, deleted in ~PresShell)
*nsCSSFrameConstructor -- mFrameConstructor (created in Init, deleted in
~PresShell)
-nsViewManager -- mViewManager (set in Init, cleared in Destroy)
+nsSelection -- mSelection set in Init, released ~PresShell)
#nsFrameManager -- mFrameManager
// XXXbz there are some weird comments at the top of nsIPresShell about
ownership; sort them out.
// XXXnote: let jwatt know how this pans out
|nsSelection:
-PresShell -- mShell (set in Init, never cleared XXX this is buggy)
|nsPresContext:
// XXXbz this isn't done yet
-PresShell -- mPresShell (set in , cleared in )
+nsDeviceContext -- mDeviceContext (set in , cleared in )
-nsWebShell -- mLinkHandler (set in SetLinkHandler by document viewer,
cleared in same) XXXbz finish this
=nsWebShell -- mContainer (set in SetContainer by document viewer) XXXbz finish
|nsEventStateManager:
-nsPresContext -- mPresContext (set and cleared in SetPresContext
[via nsPresContext::Init and ~nsPresContext respectively]
XXX this is refcounted, so can outlive the prescontext, but doesn't seem
to deal so well (never null-checks it, e.g.)
+nsDocument -- mDocument (set in EnsureDocument, sorta ad-hoc,
released in ~nsEventStateManager).
XXX it's not clear to me why we have a member here... And
EnsureDocument() doesn't ensure anything if the prescontext is null. Fix
things here.
nsStyleSet:
-nsPresContext -- mRoot->mPresContext (set in Init, cleared in Shutdown)
nsCSSFrameConstructor:
-nsDocument -- mDocument (set in constructor, never cleared)
-PresShell -- mPresShell (set in constructor, never cleared)
|nsViewManager:
-PresShell -- mViewObserver (set in SetViewObserver [via PresShell::Init],
cleared in ~nsViewManager and in
SetViewObserver [via PresShell::Destroy])
-nsDeviceContext -- mContext (set in Init, cleared in ~nsViewManager)
// XXXbz the comments here seem wrong. The device context doesn't hold a
// ref to us. Perhaps this should be a strong ref?
nsFrameManager:
-PresShell -- mPresShell (set in Init, cleared in Destroy)
-nsStyleSet -- mStyleSet (set in Init, never cleared XXX this is wrong)
XXX do we even need an mStyleSet? Why not use mPresShell->StyleSet() ?
-nsPresContext -- via mRootFrame (set in SetRootFrame, cleared in Destroy)
-nsPresContext -- via mUndisplayedMap (cleared in Destroy)
------------------------------------------------------------
Unknown lifetime:
------------------------------------------------------------
|nsDeviceContext:
Seems to have no members we care about here
Aaron Leventhal
My concern would be that we'll find a lot of places where we
assume 1 presshell and that those will be difficult to find.
We tried to not assume that in mozilla/accessible
Would there be a way to deal with this in script. For
example, if a script wanted to get the accessible object for
a given DOM node, the presshell would need to be part of the
call to nsIAccessibilityService::GetAccessibleFor(). The
presentation affects how accessibility is exposed -- we care
about things like bounds and whether things are partially or
fully offscreen. Each accessible must know what presShell
it's in so that it can return that information.
- Aaron
Robert O'Callahan
> Would there be a way to deal with this in script. For example, if a
> script wanted to get the accessible object for a given DOM node, the
> presshell would need to be part of the call to
> nsIAccessibilityService::GetAccessibleFor(). The presentation affects
> how accessibility is exposed -- we care about things like bounds and
> whether things are partially or fully offscreen. Each accessible must
> know what presShell it's in so that it can return that information.
The DOM defines "views" which are basically presentations. This is what
you would want to use here.
http://www.w3.org/TR/DOM-Level-2-Views/
Rob
Robert O'Callahan
> We support multiple presentations of the same document. We
> currently use this for printing. We should probably be using it for
> print preview if print preview weren't a total hack (we actually
> might be). In theory we could also use it for things like multiple
> views in editors, although nobody's done that.
>
> One school of thought says we should remove this and switch printing
> to clone the document. The other says that this doesn't hurt us
> much and can be quite useful.
I've hummed and hawed over this question myself. I used to think that
multiple presentations was incompatible with XBL, but I was wrong.
Still, there are DOM interfaces that don't account for multiple
views/presentations (e.g. offset*), and adding that support would
inevitably complicate the Web programming model.
Currently things are basically OK as long as non-default views don't
support scripting, and that's true for us since our only non-default
view is for printing. But for printing and print preview I think we
should just clone the DOM, because that gives us other major benefits.
This could be used in other non-dynamic situations that need multiple
presentations.
Another issue is rendering replication via SVG 'use' or table
header/footer repetition. That sounds marginal but it's a useful
capability that I think will creep in in other contexts. If we need to
replicate an IFRAME, should that use the multiple presentation
mechanism? Personally, I think not. I think content replication should
work by allowing multiple primary frames per content node, so most
places that do GetPrimaryFrameFor will need to be turned into a loop
over a primary frame list. Then we could support replicated subdocuments
by creating multiple root frames for a document. Yes, this would be a
lot like multiple presentations, but it would share mechanism with
intra-document rendering replication, and it's less general (thus
hopefully simpler) that multiple presentations because a lot of
properties are forced to be the same across replicas --- style sheets,
output device, etc.
This frame replication mechanism would also let you build a multi-paned
editor. You just wouldn't be able to apply different style sheets to the
panes. You would be able to style things differently in different panes,
though, I think, using rules like "#pane1 p { ... }".
Rob
L. David Baron
Although for at least some purposes I suspect that what end users
using tools that use the accessibility APIs want is not details
about a particular view of the document, but rather an additional
view of the document. In other words, an aural rendering of a
document should be its own view -- this allows it to be styled
independently (via CSS), etc., although its focus could later be
synchronized with another view (e.g., by keeping the input focus,
plus a second concept of focus -- the material currently being read
or currently visible, in sync between the two views).
That said, I'm not familiar with the range of software that uses the
accessibility APIs, or whether a single accessibility API can really
give the best user experience for that range of software.
Brian Ryner
when printing starts, a second PresContext and PresShell are created for the
document and it is reflowed within that shell. The PresContext has its
various parameters set to the correct values for printing (no animations,
etc).
On 10/25/06, Peter Kasting <pkas...@google.com> wrote:
>
> Aaron Leventhal wrote:
> > Why do our interfaces allow for multiple presshells?
> >
> > Is it possible to have more than one? If not, shouldn't we clear this
> up?
>
> If I recall bryner's comments accurately, we can have two: the 0th
> presshell, which is the "normal" one, and the 1st, which is the
> "printing" presshell.
>
> > Do we have docs on how this works including the ownership
> > model?
>
> I've seen a couple graphical representations of this, but I can't
> remember where they are at the moment. darin or bryner should know, I
> think.
>
> PK
>
--
-Brian