A possible route to improving tab handling within Thunderbird's main windows
mbanner at mozilla.com
Fri Aug 10 14:46:31 UTC 2012
I mentioned this in one of the papercut threads previously, relating to
resolving the issue around handling message tabs and the scroll
positions being reset <https://bugzilla.mozilla.org/show_bug.cgi?id=487386>.
The fundamental issue here is that the element that shows the message
(id = "messagepane") is currently shared across all the message tabs.
Additionally, the rest of the elements of the three-pane window are also
shared across the message tabs (but for some tabs, elements get hidden,
so you don't see the folder pane or message list in the single-message tab).
However, in resolving that, there's also more steps that could be taken
to improve tab handling in general, and some extra bits of the UI.
The plan I've thought about previously is given below. There may be a
few bits wrong/out of order, as it has been a few months since I last
thought about it and since I was active in that bit of the code. The
ordering is probably roughly in the order you'd want to do it, but it
may need thinking about a bit more, I'll try and explain the reasons as
I go through.
Two preparatory steps are:
* Ensure that all the relevant message window command elements (e.g.
menu options, buttons etc) go through a controller that is hooked
into tab types for message based tabs
o This will ensure that when switching to non-mail tabs the
relevant options are disabled
o I think this may largely work today, but I believe it isn't
actually hooked into the tab type
* Find instances in the code where we refer to elements with ids of
"messagepane" and replace by alternate methods which do not rely on
that specific id
o For example, there are places in gecko that look for the
"messagepane" id, e.g.
o Some of these have been replaced over the years, but as seen
above there's still some in use. The mail code base also has
lots of references that would need to be replaced with an
There's then some steps that could be done in parallel, or may even be
* Define a new tab type for the single message tab that does not
re-use the 3-pane window structure
o The goals here would be to have completely separate elements for
each message tab, which would then obviously resolve some of the
main issues with message tabs re-loading messages
o I suspect there would need to be some work around the message
display objects, as well as some more general fixes to ensure
all the functions kept working
* Implement a home tab
o We intended a project
this before, but unfortunately it didn't really get started
o The basic idea was for some kind of default tab that wasn't the
three-pane, but would be displayed when no other tabs were
present (see more reasons below)
o The GSoC App tabs project would probably be a good starter for this
Then going back to some more ordered steps:
* Alter the Gloda search tab to not re-use the 3-pane window structure
o Obviously heading in the same direction as the single message tab
o Again I would expect some more general re-work, although this
should also start helping with the next step
* Alter the 3-pane tab to not re-use its elements
o The final step in the message tab switching handling improvements
o Most of the preparation for it should have been done already,
and so it should be a smaller step
As an added bonus we could then:
* Replace the standalone message window
o I could foresee this being replaced by the 3-pane window with a
single message tab shown
o The tabs could be hidden if just a single message was shown, to
make it feel the same as it does now
o It would reduce the code complexity that we have now, that is
caused by the two different window types
o Message tabs torn-out of the main window could become single
o Any tab type could be torn-out and placed into another window
(showing the tabs if necessary)
o The home tab could also be used as a kick-start for tabs in a
new window, e.g. for extensions like Lightning, or just not
showing message tabs at all to being with
There's probably some more hidden work in here as well, it sounds like a
lot, but I think the real complexities are reducing the dependence on
the id of "messagepane" and then separating out the tabs which include
the folder/message list views.
I'm offering this up as a possible route should folks want to work on
it, obviously I'm not planning on working on it myself at the moment,
but I'll be happy to answer general questions here or detailed questions
etc on irc/bugs as appropriate.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning