A possible route to improving tab handling within Thunderbird's main windows

[Mark Banner]

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.

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
• e.g. http://hg.mozilla.org/comm-central/annotate/2019e8845fbf/mail/base/content/specialTabs.js#l356
• This will ensure that when switching to non-mail tabs the relevant options are disabled
• 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
• For example, there are places in gecko that look for the "messagepane" id, e.g. http://hg.mozilla.org/mozilla-central/annotate/b5ae446888f5/content/html/document/src/PluginDocument.cpp#l211 and http://hg.mozilla.org/mozilla-central/annotate/b5ae446888f5/toolkit/content/charsetOverlay.js#l253
• 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 alternate version

There's then some steps that could be done in parallel, or may even be optional:

• Define a new tab type for the single message tab that does not re-use the 3-pane window structure
• 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
• 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
• We intended a project for this before, but unfortunately it didn't really get started
• 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)
  
• 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
• Obviously heading in the same direction as the single message tab
• 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
• The final step in the message tab switching handling improvements
• 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
• I could foresee this being replaced by the 3-pane window with a single message tab shown
• The tabs could be hidden if just a single message was shown, to make it feel the same as it does now
• It would reduce the code complexity that we have now, that is caused by the two different window types
  
• Message tabs torn-out of the main window could become single message tabs
• Any tab type could be torn-out and placed into another window (showing the tabs if necessary)
  
• 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.

Mark.