Open Bug 514476 Opened 15 years ago Updated 10 years ago

mail.tabs.autoHide does nothing on SeaMonkey

Categories

(SeaMonkey :: Preferences, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: tonymec, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [workaround: comment #3])

Attachments

(3 obsolete files)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090902 SeaMonkey/2.0b2pre - Build ID: 20090902002520

mail.tabs.autoHide (which IIUC is the pref to autohide the mailer tabbar when only one tab is present) has no effect in SeaMonkey. The preference browser.tabs.autoHide (for the browser tabbar) always applies to both browser & mailer

Reproducible: Always

Steps to Reproduce:
1. Make sure you're using a SeaMonkey 2 nightly dated 2009-09-01 or later (because earlier than that, SeaMonkey had no tabbed mailer).
2. Edit => Preferences => Browser => Tabbed browser => uncheck [ ] Hide the tab bar when only one tab is open.
3. In about:config, create the preference mail.tabs.autoHide with type Boolean and value true.
4. Look at the mailer window.
5. Make sure you don't have more than one mailer tab

Actual result:
There is a tab bar in the mailer (the browser pref is not overridden by the mailer pref)

Expected result:
There should be no tab bar in the mailer.

Additional info:
* The pref name was obtained from http://kb.mozillazine.org/Thunderbird_3.0_-_New_Features_and_Changes#Message_and_Folder_Tabs
* Now that the tabbed mailer has landed in SeaMonkey, its preferences ought to apply to Sm as well as Tb.
* Closing and reopening the mailer window changes nothing. (Note: toggling the browser pref applies immediately in the mailer even with no restart.)
There is no mail.tabs.autoHide in SM, we use the browser.tabs.* prefs for all ;-) tabbrowsers in SM.

There's a bug with hiding the last tab, though, see bug 514177.
DUPE theis one?
Interesting, the discussion in bug 460960 comment #9 and following still mentions that main.* prefs should override the browser.* prefs, apparently
this idea was removed later in the process (without reading all 120+ comments
in that bug).

There is also bug 513905 for introducing mail.* counterparts to browser.* prefs where it is deemed useful.

BTW: This is not a dupe of 514177, which reported a bug in the algorithm to figure out whether the last tab was closed and then hiding the bar.
In reply to comment #2

IMHO it would be "useful" to be able to decide separately whether to hide or not to hide the mailer vs. browser tabbar when each of them has only one tab. (My preference would be: hide in the mailer, don't hide in the browser, but if other people prefer the opposite, why not?)

mail.tabs.autoHide is mentioned at bug 51305 comment #1 (currently the latest comment) so I'm making this bug a blocker of 51305.

Temporarily leaving this bug's Summary unchanged but it might be appropriate to change it someday to "Create preference mail.tabs.autoHide", be it either "for SeaMonkey" (or for MailNewsCore in general).

As a possible workaround, the following code in userChrome.css will _always_ hide the mailer tabbar regardless of other settings:

/*
 * Don't display tabs in mail (3-pane) window
 */
.tabmail-strip
  { display:            none            !important
  }

It is, of course, not ideal, and in particular not specific enough. But it works.
Blocks: 51305
oops... bug 513905 comment #1, not 51305
Blocks: 513905
No longer blocks: 51305
No longer blocks: 513905
Depends on: 513905
Er, Ian, I see you changed this bug to "be blocked" by the meta bug 513905 instead of "blocking" it. I don't understand the logic of that. I would expect the patch implementing mail.tabs.autoHide to be worked out within this bug (or some bug of which this one would be a dupe), starting immediately, and preventing the close of the metabug as long as work is in progress here.
Blocks: 513905
No longer depends on: 513905
Here is a patch that allows tabmail to use mail.tabs.autoHide if it is present (i.e., if the user added it via about:config or user.js).  Otherwise, it falls back to browser.tabs.autoHide as before.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #404470 - Flags: review?(mnyromyr)
Flags: wanted-seamonkey2.0?
Attachment #404470 - Flags: superreview?(neil)
(In reply to comment #6)
> Created an attachment (id=404470)
> Use mail.tabs.autoHide if available
What about other prefs, such as closeButtons?

If we had two pref branches (one for "browser.tabs." and one for "mail.tabs.") then you could observe the same pref name in both branches.
(In reply to comment #7)
> (In reply to comment #6)
> > Created an attachment (id=404470) [details]
> > Use mail.tabs.autoHide if available
> What about other prefs, such as closeButtons?
> 
> If we had two pref branches (one for "browser.tabs." and one for "mail.tabs.")
> then you could observe the same pref name in both branches.
Presumably if mail.tabs.autoHide exists then we only want to observe that, not browser.tabs.autoHide?
Also if you start using this pref then need to:
1/ Add this pref as something that is migrated from a TB profile.
2/ Expose this pref in pref pane.
3/ Update help to reflect this pref and the updated pref pane.

These could potentially be spun off into other bugs though.
(In reply to comment #7)
> What about other prefs, such as closeButtons?

Since those prefs don't currently have an effect on tabbrowser, they are exclusive to tabmail for now (despite the names), so I figured that they could be taken care of in a separate bug once tabbrowser is updated to use them.

The only one that also affects tabbrowser is loadInBackground, but that one is used in suite/common as well, so the patch would be much more complicated and probably belongs in a separate bug as well.

> If we had two pref branches (one for "browser.tabs." and one for "mail.tabs.")
> then you could observe the same pref name in both branches.

Thanks, I changed that in this updated patch.

(In reply to comment #8)
> Presumably if mail.tabs.autoHide exists then we only want to observe that, not
> browser.tabs.autoHide?

I considered that, but there's the (somewhat unlikely) chance that someone could delete mail.tabs.autoHide while MailNews is running.  It would be a possibility to add the observer back at that point, though.
Attachment #404470 - Attachment is obsolete: true
Attachment #404729 - Flags: superreview?(neil)
Attachment #404729 - Flags: review?(mnyromyr)
Attachment #404470 - Flags: superreview?(neil)
Attachment #404470 - Flags: review?(mnyromyr)
Basically, we need to decide first what kind of "pref inheritance" we want.
browser.tabs.* have default values and will never fail - should mail.tabs.* have default values of its own (=never inherit) or should it just inherit browser.tab.* settings when you don't provide your own mail.tabs.* settings?
(Personally I prefer the latter, since you usually won't have different settings, I presume.)

If we allow a specific mail.tabs.X to fall back unto browser.tabs.X, what should happen if both are the same? Should we delete mail.tabs.X to enable the fallback? Otherwise changes to browser.tabs.X won't be picked up?

If we "officially" allow different settings for mail.tabs.*, that should have probably have its own pref pane as well. (We could go without that first and shoot for 2.1 with that.)

(In reply to comment #8)
> Presumably if mail.tabs.autoHide exists then we only want to observe that, not
> browser.tabs.autoHide?

Watching just mail.tabs.autoHide doesn't make sense anyway, we'd need to watch both whole branches and act/look on both branches upon changes:
- If mail.tabs.X changes, do whatever has to be done.
  - If mail.tabs.X == browser.tabs.X, do what?
- If browser.tabs.X changes and mail.tabs.X exists, ignore the change.
- If browser.tabs.X changes and mail.tabs.X does not exist, do whatever has to be done, just as if mail.tabs.X would have been set.
Comment on attachment 404729 [details] [diff] [review]
Use mail.tabs.autoHide if available v2

>+            let prefBranch = (this.mailPrefBranch.getPrefType("autoHide") ==
>+                              Components.interfaces.nsIPrefBranch.PREF_BOOL) ?
Nit: I'd prefer prefHasUserValue. (And you didn't need the ()s.)

+                              this.mailPrefBranch : this.browserPrefBranch;
Hmm, should these be called mMailPrefBranch and mBrowserPrefBranch?
Attachment #404729 - Flags: superreview?(neil) → superreview+
Thanks for the sr+, Neil.  Carrying it over to this updated patch.

(In reply to comment #12)
> Nit: I'd prefer prefHasUserValue. (And you didn't need the ()s.)

Fixed.

> Hmm, should these be called mMailPrefBranch and mBrowserPrefBranch?

Fixed.

(In reply to comment #11)
> Basically, we need to decide first what kind of "pref inheritance" we want.

In this patch, mail.tabs.autoHide is used if it is present.  If not, it falls back to using browser.tabs.autoHide.  If the two prefs are the same, nothing is changed.  Do you think that would be acceptable for this pref, at least for 2.0 (especially considering that mail.tabs.autoHide would remain a hidden pref for now)?  If necessary, the inheritance behavior for this pref can be revisited for 2.1 when work is done to allow more tab prefs to be overridden.
Attachment #404729 - Attachment is obsolete: true
Attachment #404956 - Flags: superreview+
Attachment #404956 - Flags: review?(mnyromyr)
Attachment #404729 - Flags: review?(mnyromyr)
Comment on attachment 404956 [details] [diff] [review]
Use mail.tabs.autoHide if available v2.1

Looks like the patch didn't make 2.0. :(  In that case, I guess the review can wait until more discussion has taken place regarding comment #11.
Attachment #404956 - Flags: review?(mnyromyr)
Flags: wanted-seamonkey2.0?
Krang, it might still be possible to get it into 2.0 if you request approval - but I think Mnyromyr should review this as well.
Comment on attachment 404956 [details] [diff] [review]
Use mail.tabs.autoHide if available v2.1

(In reply to comment #15)
> Krang, it might still be possible to get it into 2.0 if you request approval -
> but I think Mnyromyr should review this as well.

Thanks, I'll request approval and re-request review.
Attachment #404956 - Flags: review?(mnyromyr)
Attachment #404956 - Flags: approval-seamonkey2.0?
Comment on attachment 404956 [details] [diff] [review]
Use mail.tabs.autoHide if available v2.1

I'm not sure that fixing up just this single pref is overly useful for 2.0, especially since after some discussion we came to the conclusion to totally separate the tab prefs for 2.1 by:
- replacing all browser.tabs.* by mail.tabs.* in mailnews
- creating /suite/mailnews/mailnews-prefs.js (mimicking browser-prefs.js handling) and putting all needed default values there (kind of starting with bug 496429)
- creating a separate tabmail pref pane

Fixing only parts of this for 2.0 would be either confusing or futile, especially given the time constraints.
Attachment #404956 - Flags: review?(mnyromyr)
Attachment #404956 - Flags: review-
Attachment #404956 - Flags: approval-seamonkey2.0?
Attachment #404956 - Flags: approval-seamonkey2.0-
Fair enough.  For 2.0, there's always the workaround in comment #3 for those who want the tab strip to always be visible in the browser but not in mailnews.  This bug can probably be duped once there is a new bug for the work you mentioned.
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
Attachment #404956 - Attachment is obsolete: true
(In reply to comment #18)
> Fair enough.  For 2.0, there's always the workaround in comment #3 for those
> who want the tab strip to always be visible in the browser but not in mailnews.
>  This bug can probably be duped once there is a new bug for the work you
> mentioned.
Can I just thank you for the work you put in to this bug, it was appreciated.
Whiteboard: [workaround: comment #3]
thanks for the workaround in comment #3
it does exactly what I wanted.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: