<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I mentioned this in one of the papercut threads previously, relating
    to resolving the <a
      href="https://bugzilla.mozilla.org/show_bug.cgi?id=487386">issue
      around handling message tabs and the scroll positions being reset</a>.<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Two preparatory steps are:<br>
    <ul>
      <li>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</li>
      <ul>
        <li>e.g.
<a class="moz-txt-link-freetext" href="http://hg.mozilla.org/comm-central/annotate/2019e8845fbf/mail/base/content/specialTabs.js#l356">http://hg.mozilla.org/comm-central/annotate/2019e8845fbf/mail/base/content/specialTabs.js#l356</a></li>
        <li>This will ensure that when switching to non-mail tabs the
          relevant options are disabled</li>
        <li>I think this may largely work today, but I believe it isn't
          actually hooked into the tab type</li>
      </ul>
      <li>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</li>
      <ul>
        <li>For example, there are places in gecko that look for the
          "messagepane" id, e.g.
          <a class="moz-txt-link-freetext" href="http://hg.mozilla.org/mozilla-central/annotate/b5ae446888f5/content/html/document/src/PluginDocument.cpp#l211">http://hg.mozilla.org/mozilla-central/annotate/b5ae446888f5/content/html/document/src/PluginDocument.cpp#l211</a>
          and
<a class="moz-txt-link-freetext" href="http://hg.mozilla.org/mozilla-central/annotate/b5ae446888f5/toolkit/content/charsetOverlay.js#l253">http://hg.mozilla.org/mozilla-central/annotate/b5ae446888f5/toolkit/content/charsetOverlay.js#l253</a></li>
        <li>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</li>
      </ul>
    </ul>
    <p>There's then some steps that could be done in parallel, or may
      even be optional:<br>
    </p>
    <ul>
      <li>Define a new tab type for the single message tab that does not
        re-use the 3-pane window structure</li>
      <ul>
        <li>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</li>
        <li>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</li>
      </ul>
      <li>Implement a home tab</li>
      <ul>
        <li>We <a
            href="https://wiki.mozilla.org/Features/Thunderbird/Home_Tab">intended
            a project</a> for this before, but unfortunately it didn't
          really get started</li>
        <li>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)<br>
        </li>
        <li>The GSoC App tabs project would probably be a good starter
          for this</li>
      </ul>
    </ul>
    <p>Then going back to some more ordered steps:<br>
    </p>
    <ul>
      <li>Alter the Gloda search tab to not re-use the 3-pane window
        structure</li>
      <ul>
        <li>Obviously heading in the same direction as the single
          message tab</li>
        <li>Again I would expect some more general re-work, although
          this should also start helping with the next step</li>
      </ul>
      <li>Alter the 3-pane tab to not re-use its elements</li>
      <ul>
        <li>The final step in the message tab switching handling
          improvements</li>
        <li>Most of the preparation for it should have been done
          already, and so it should be a smaller step</li>
      </ul>
    </ul>
    <p>As an added bonus we could then:<br>
    </p>
    <ul>
      <li>Replace the standalone message window</li>
      <ul>
        <li>I could foresee this being replaced by the 3-pane window
          with a single message tab shown</li>
        <li>The tabs could be hidden if just a single message was shown,
          to make it feel the same as it does now</li>
        <li>It would reduce the code complexity that we have now, that
          is caused by the two different window types<br>
        </li>
        <li>Message tabs torn-out of the main window could become single
          message tabs</li>
        <li>Any tab type could be torn-out and placed into another
          window (showing the tabs if necessary)<br>
        </li>
        <li>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<br>
        </li>
      </ul>
    </ul>
    <p>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.<br>
    </p>
    <p>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.<br>
    </p>
    <p>Mark.<br>
    </p>
  </body>
</html>