Multiple presshells

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple presshells

Aaron Leventhal-3
Why do our interfaces allow for multiple presshells?

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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

Peter Kasting
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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

L. David Baron
In reply to this post by Aaron Leventhal-3
On Wednesday 2006-10-25 12:53 -0400, Aaron Leventhal wrote:
> 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

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

Boris Zbarsky
In reply to this post by Aaron Leventhal-3
Aaron Leventhal wrote:
> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Re: using it for more printing --
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

L. David Baron wrote:

> On Wednesday 2006-10-25 12:53 -0400, Aaron Leventhal wrote:
>> 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
>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

Robert O'Callahan-3
Aaron Leventhal wrote:
> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

L. David Baron
On Thursday 2006-10-26 20:24 +1300, Robert O'Callahan wrote:

> Aaron Leventhal wrote:
> >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/
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.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

Robert O'Callahan-3
In reply to this post by Aaron Leventhal-3
L. David Baron wrote:
> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Multiple presshells

Brian Ryner-2
In reply to this post by Peter Kasting
I believe that's right, but it's been awhile since I've looked at it.  iirc,
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 <[hidden email]> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout