902312 - Tabbed mail in 3-pane window does no longer observe browser.tabs.autoHide for display of single tabs

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[rsx11m]

Tabbed mail used to observe the browser.tabs.autoHide preference to determine whether or not to show the tabbar when only a single tab is active.

Noticed on aurora nightly builds after rotating versions with the last merge:

 - 2.21a2 still shows no tabbar for a single tab with browser.tabs.autoHide set
 - 2.22a2 shows the tabbar for a single tab despite browser.tabs.autoHide set

Earliest build of that branch I have exhibiting the problem: 2.22a1 20130712

Comment 1

[Alex Macfarlane Smith]

This bug also seems to be present in Firefox 23.0 (I can raise a separate bug if you prefer).

Comment 2

[rsx11m]

Firefox doesn't have a Mail & News component (SeaMonkey's browser isn't affected). What you are most likely looking at is the effect of bug 855370 - Remove the ability to not "Always show the tab bar" - which is separate from SeaMonkey's implementation.

Also, given that SeaMonkey 2.20 isn't affected, this doesn't appear to be a fallout from the Firefox bug, unless they have removed supporting Core parts in the process (but then again, I'd expect the browser tabbar to behave the same way).

Thus, while Firefox removed the functionality on purpose, it should be a genuine regression in SeaMonkey's Mail & News component.

BTW: https://addons.mozilla.org/firefox/addon/hide-tab-bar-with-one-tab/ adds the lost functionality back to Firefox, but that's yet another add-on needed there.

Comment 3

[rsx11m]

Works:  Linux i686 trunk nightly build of 2013-06-29;
Broken: Linux i686 trunk nightly build of 2013-07-01.

There was no 2013-06-30 trunk nightly build for any platform.

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2013-06-29&enddate=2013-07-01+05%3A00
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-06-29&enddate=2013-07-01+05%3A00

Comment 4

[Philip Chee]

fallout from Bug 653881 (Fix up our XBL1 shadow tree implementation so that we can reuse it for XBL2 )

http://hg.mozilla.org/comm-central/annotate/d2fe0ebc74db/suite/mailnews/tabmail.xml#l191

          <xul:tabs class="tabbrowser-tabs tabmail-tabs"
......
            <xul:tab selected="true"
......
            <children/>

After bug 653881, <children> is an explicit DOM node. With one tab open there are now two childnodes.

http://hg.mozilla.org/comm-central/annotate/d2fe0ebc74db/suite/mailnews/tabmail.xml#l273

      <property name="mAutoHide" onget="return this._mAutoHide;">
        <setter>
          <![CDATA[
            if (val != this._mAutoHide)
            {
              if (this.tabContainer.childNodes.length == 1)
                this.mStripVisible = !val;
              this._mAutoHide = val;
            }
            return val;
          ]]>
        </setter>
      </property>

Changing this to:
              let tabs = this.tabContainer.querySelectorAll(".tabmail-tab");
              if (tabs.length == 1)
Works but there are other places that need to be fixed

Comment 5

[[e-mail]]

Attachment: Possible patch

By inserting the tabs before the xbl:children node we at least get all the nodes consecutively.

Comment 6

[Philip Chee]

Comment on attachment 787836 [details] [diff] [review]
Possible patch

This works until I open a calender tab or two.

What about: <method name="_updateTabsVisibilityStatus"> ?

>       <handler event="popupshowing">
>         <![CDATA[
>           // set up the menu popup
>           let tabcontainer = document.getBindingParent(this);
>           let tabs = tabcontainer.childNodes;

The all tabs popdown menu has an extra blank entry at the end.

Comment 7

[[e-mail]]

Attachment: Proposed patch

I had another look into this and the problem is worse than I thought; even the base <tabs> binding gets confused by the extra xbl:children child node. So the only solution I could find was to put the Calendar buttons after the dropdown. Thunderbird's tabs on top had to remove that trick with the rest of their xbl, which means that we're not missing out on anything.

Comment 8

[Philip Chee]

Comment on attachment 797766 [details] [diff] [review]
Proposed patch

The UI is sub-optimal but at least it works.

Calendar tabs can be closed with the [x] close button or from the tab context menu. CTRL-W doesn't work on calendar tabs. But I think this problem is not related to this bug.

Comment 9

[[e-mail]]

Pushed comm-central changeset 781c3bd778c5.

Comment 10

[[e-mail]]

Comment on attachment 797766 [details] [diff] [review]
Proposed patch

[Approval Request Comment]
Regression caused by (bug #): 653881
User impact if declined: Mail tabs don't operate correctly
Testing completed (on m-c, etc.): Port of Thunderbird change
Risk to taking this patch (and alternatives if risky): Low
String changes made by this patch: None

Comment 11

[Jens Hatlak (:InvisibleSmiley)]

Please make sure this gets landed in time for the final 2.22 beta at the latest.

Comment 12

[[e-mail]]

https://hg.mozilla.org/releases/comm-aurora/rev/d60fd92ab4cf
https://hg.mozilla.org/releases/comm-beta/rev/1bc86c2043b3

Comment 13

[rsx11m]

Verified fixed Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 SeaMonkey/2.23a2
Build identifier: 20131019013001.

Comment 14

[rsx11m]

Also verified with 2.22 beta 2, Build identifier: 20131023190953.