UX Priorities.

Andrew Sutherland 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[1], 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 mailing list