asutherland at asutherland.org
Thu Mar 29 19:23:03 UTC 2012
On 03/29/2012 11:32 AM, Magnus Melin wrote:
> This is https://bugzilla.mozilla.org/show_bug.cgi?id=487386 - and yes,
> it's probably the most annoying tab bug we have.
It's worth calling out that while hacking persistence of the scroll
position is a easy-but-brittle fix, the underlying problem is that
our 3-pane tabs are multiplexed so that they all use the same widgets
and is a more complex/potentially breaking set of changes.
When we change tabs, we swap out the nsITreeView/nsMsgDBView backing the
thread-pane and re-stream the message. The major upside of this is that
the multiplicity of the message reader and the thread pane has always
been 1. Extensions can listen for MsgMsgDisplayed and are at no risk of
getting confused by dealing with multiple tabs because we either swap
the references of a number of globals (gFolderDisplay, gMessageDisplay)
or there really is just one global (currentHeaderData).
The tradition of having only a single effective JS namespace/global per
window has also been maintained through this. (The contrasting example
is that the faceted search UI lives in an iframe. The multi-message
summaries, however, are loaded by messenger.xul and I believe just use
the iframe as a DOM they can manipulate.)
The dominant potential fixes are
1) Encapsulate each tab entirely in its own (XUL) iframe. This breaks
extensions, but can potentially just be fixed by changing their overlay
URL and potentially simplifies their lives because their code gets
instantiated once per tab. Invariants about accessing things by DOM ids
will be maintained.
2) Leverage the tab implementation and FolderDisplayWidget to swap out
what are currently presumed singleton globals, as well as possibly
changing who gets labeled with specific DOM ids (and changing existing
CSS on DOM ids to be on css class.) Some extensions would probably
survive without changes if all of their activity occurs synchronously on
MsgMsgDisplayed notifications and we are careful to only issue them for
the foreground tab. If attempting to provide perfect
backwards-compatibility, XUL overlay contributions and their CSS would
probably need to be processed at window load-time to ensure that some
type of cloning would be successful by re-writing #id rules to class
rules and inferring DOM ids that would need to be switched on tab changes.
I think no matter what happens, extensions would break and need to be
updated, so a lot of the question would be which model is less horrible
for development of Thunderbird and extensions.
1: It's easy to save off the scroll position. However, if we still
re-stream the message when tabs are switched, we may have to wait for
the message to stream enough to restore the scroll position. This will
tend to be visually glitchy.
More information about the tb-planning