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

Mark Banner 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 e.g.
        http://hg.mozilla.org/comm-central/annotate/2019e8845fbf/mail/base/content/specialTabs.js#l356
      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.
        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
      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
        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
      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
        <https://wiki.mozilla.org/Features/Thunderbird/Home_Tab> for
        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
        message tabs
      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.

Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120810/85dc6f29/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120810/85dc6f29/attachment.p7s>


More information about the tb-planning mailing list