150099 - Hide the tab bar when clicking the close box

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[jag (Peter Annema)]

If a distribution wants to show the tab bar by default (even when just one tab
is visible), they'll want an easy way to hide it. Our suggestion is to reuse the
close button to hide the tab bar when only one tab is visible.

Comment 1

[jag (Peter Annema)]

Attachment: One solution which reuses the existing pref

Comment 2

[Sean Cotter]

The menu text "Tab Bar" is fine.

What happens if "Hide the tab bar when only one tab is open" is selected (in the
Tabbed Browsing pref panel), and you turn on the tab bar from the View menu?

Comment 3

[jag (Peter Annema)]

That's the part I need to work out. I'm thinking about simply disabling the
menuitems in that case.

Comment 4

[rchen]

Approved for UI change from L10n. Please checkin asap.

Comment 5

[scottputterman]

Please checkin the string changes today after getting drivers approval.  We'll
add the adt1.0.1+ when the rest of the bug is fixed.

Comment 6

[Michele Carlson]

Is this checked into the branch yet? You will lose l10n approval if this isn't
checked into the branch by Friday at the latest (6/14). 

Comment 7

[jag (Peter Annema)]

The DTD changes have been checked in on the branch, see file
browser/resources/locale/en-US/navigator.dtd

Comment 8

[jag (Peter Annema)]

Attachment: Don't reuse the existing pref. Feels much better already.

Comment 9

[jag (Peter Annema)]

Attachment: Don't reuse the existing pref. Feels much better already.

Better version, check visibility, not forceHide "pref", to set checkmark on the
show/hide menuitem.

Comment 10

[jag (Peter Annema)]

Attachment: diff -uw of above to more clearly display the changes made to updateToolbarStates in navigator.js

Comment 11

[Joe Hewitt (gone)]

Comment on attachment 88930 [details] [diff] [review]
diff -uw of above to more clearly display the changes made to updateToolbarStates in navigator.js

sr=hewitt

Comment 12

[Brian Ryner (not reading)]

Comment on attachment 88930 [details] [diff] [review]
diff -uw of above to more clearly display the changes made to updateToolbarStates in navigator.js

r=bryner

Comment 13

[Asa Dotzler [:asa]]

Comment on attachment 88930 [details] [diff] [review]
diff -uw of above to more clearly display the changes made to updateToolbarStates in navigator.js

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 14

[Asa Dotzler [:asa]]

please replace the mozilla1.0.1+ keyword with fixed1.0.1 when this lands. Thanks.

Comment 15

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) approval for checking into the 1.0 branch. pls check
this in asap, the replace mozilla1.0.1 with fixed1.0.1 keyword. thanks!

Comment 16

[jag (Peter Annema)]

Checked in.

Comment 17

[sairuh (rarely reading bugmail)]

vrfy'd fixed using branch comm bits (2002.06.25.0x) on linux rh7.2, mac 10.1.5
and win2k, as well as trunk comm bits (2002.06.25.08) on win2k and mac 10.1.5
and 9.1.

a. control: no regression found when the pref "hide the tab bar when only 1 tab
is open" is ON - the tab bar was indeed hidden, and the View > Show/Hide > Tab
Bar menu item is greyed out (not selectable).

b. when "hide the tab bar when only 1 tab is open" is OFF, the View > Show/Hide
> Tab Bar menu item is active. if the tab bar is present && only 1 tab: there'll
be a checkmark next to the menu item. either clicking the close box in the bar
or deselecting the menu item will remove the tab bar (and not close the tab
bar). likewise, if the tab bar is absent && pref is OFF, selecting the menu item
will bring back the tab bar.

c. when there's >1 tab open: the tab bar will be present (expected, whether the
pref is on or off). moreover, the menu item --while still greyed out-- will have
a checkmark. (makes sense, since the pref is off, but the bar is present due to
multiple tabs.)

Comment 18

[Chu Alan #2]

the `Hide the tab bar when only one tab is open' pref in pref box is out of sync ...

uncheck the pref, then click on X to close the tabbed browser bar, try to go to
pref box, the pref is unchecked, after mozilla restarts, the pref is STILL
unchecked, and it hides the tab bar initally, which contradicts to the pref setting.

(should i file this bug as a new bug?)

Comment 19

[jag (Peter Annema)]

The behaviour you described is as designed. Yes, the pref is unchecked (meaning
that we want to show the tab bar when there's one tab) but the user has
overridden that by manually hiding the tab bar. The aim of this was to allow
users an easy way to permanently hide the tab bar across sessions.

Comment 20

[jag (Peter Annema)]

I realize that this can lead to some confusion, I don't see a way to address
that though.

Comment 21

[Chu Alan #2]

how about just get rid of that option in the pref window (if it cannot be fixed
...) ?

Comment 22

[jag (Peter Annema)]

The option still makes sense. If you turn it on, the tab bar will automatically
hide, if you turn it off you will have to hide it manually. Perhaps the text
should be changed to something like "automatically hide the tab bar when only
one tab is open" to indicate that we'll hide the tab bar for one tab when that
option is selected (but not necessarily that we'll always show the tab bar when
the option is not selected).

Comment 23

[Jason Bassford]

It makes more sense to remove the pref altogether, change the View -> Show/Hide
text to "Tab Bar (Single Tab)" and have it checked by default.

(Shall I open another bug?)

After all, View -> Show/Hide -> Tab Bar is meaningless when more than one tab is
open anyway.  (It would only make sense if you could hide the bar with multiple
tabs, but you can't because it's greyed out.)

Comment 24

[jag (Peter Annema)]

Removing that pref would remove the functionality of having the tab bar
automatically hide. Perhaps that's okay, perhaps only a small number of people
really want the tab bar to automatically hide when there's only one tab left,
and maybe most of them will be okay with having to hide it manually. I don't
know, and before I remove that pref I'd like to know this.

Comment 25

[Jason Bassford]

Oh!  I see why now this happens - I hadn't realised.  If I uncheck View ->
Show/Hide -> Tab Bar with one tab (so it's hidden), open another tab, and then
close it - the tab bar remains open.  So the act of opening a 2nd tab
automatically checks it again.  You're right that you need to pref too as things
stand.  But.

I suggest that the View -> Show/Hide -> Tab Bar remain a sticky setting.  If
it's checked, then the Tab Bar will always be visible; if it's unchecked then it
will always auto-hide. (And it can be checked by default so it's visible to new
users.)   Don't have opening a 2nd tab change its status. That way everything
functions just as it used to but without the need for the preference, and it
also accomodates the functionality of the tab close button.

It may be slightly confusing to have the tab bar shown with multiple tabs and
have View -> Show/Hide -> Tab Bar unchecked but it can either stay that way or,
as mentioned, the text can be modified to "Tab Bar (Single Tab)" for clarity.

Comment 26

[jag (Peter Annema)]

Well, there really are two prefs. One is for whether to hide the bar
automatically, the other is more like a persistent store to keep track of
whether the user currently wants the tab bar hidden (even though he didn't want
it to automatically hide).

Comment 27

[Jeremy M. Dolan]

Is a view menu entry necessary, and if so, why, when "Hide tab bar w/ 1 tab" is
enabled, is tab bar there greyed out so you can't turn it on?

Comment 28

[Basil Fritts]

It is difficult to comprehend, surrounded by so much mud and so many mosquitoes,
why someone thought it was a good idea to create a swamp.

The behavior that has been created by this bug is fundamentally
counterintuitive, producing results that cannot be predicted or expected by the
user. (Unless you expect them to read this bug.)

When I enable the tab bar in the prefs dialog, I expect this preference to have
some permanence. I further would expect that the close button on the tab bar
would become inactive. (There was a bug about this: bug 109651.)
Incomprehensibly, it does not become inactive. (In fact, I would consider this a
regression on bug 109651.) Clicking it closes the bar which I specifically
*enabled* in the prefs dialog. Moreover, when I look at the pref again, it is
*still* enabled. So, for reasons that I cannot understand the behavior that I
specifically requested to be enabled has been disabled, and the UI is telling me
that it *is* still enabled. Surely this is a bug.

NO? It's a feature? Oh. I must be logging bugs against the dominant browser now,
because that's $bug = $feature thinking there.

The stated rationale for this behavior is to provide an easy UI hook for
disabling the tab bar. Fine. The view menu is the place for disabling toolbars.
No other toolbar has a button for hiding it.

Moreover, this overloads the Close Tab UI widget causing it to act
unpredictably. (Unless you expect users to read b.m.o. Don't make me laugh.)

I propose reopening this bug. I further propose reopening bug 109651 and depping
it to this one. The bug that is deemed most losing should be closed WONTFIX. You
can guess which one will get my vote.

Comment 29

[Jeremy M. Dolan]

The second paragraph of Basil's little rant is disgustingly true I don't know
whether to laugh or puke. When I first saw this UI after the check-in, I thought
it was terrible but shrugged it off, since I auto-hide the bar when only one tab
is open.

Halfway through his comment I realized the only SANE thing to do is disable the
close button, which further down I saw had already been filed. Please reconsider
this fix, or someone at NSCP point out the horridness of this approach to your
superiors. I can't believe NSCP would prefer this fix over 109651 in their
commercial product.

Comment 30

[Jason Bassford]

This bug is marked FIXED.  The only reason to reopen it would be if the code
checked in did not work as intended.  You can't reopen a FIXED bug only to
withdraw the code and mark it WONTFIX.  (At least I've never heard of that before.)

For further discussion please go to the newsgroups.  If you want to open a bug
to remove the now current behaviour, please do that (make sure to CC
[e-mail] if you do).  But please stop SPAMming this particular bug.