231342 - When toolbar is hidden all open tabs are hidden, leaving only the current one on display (Mac OS X)

Status: RESOLVED FIXED

(Firefox :: Shell Integration, defect, P2)

Description

[Eric D.]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7

When you hide the toolbar using the button on the top-right of the window (in
Mac OS X) all background tabs open in the current window are hidden. Only the
tab being shown will be visible.

Reproducible: Always

Steps to Reproduce:
1.Open up a number of tabs and make sure the tabs are visible
2.Click on button in top-right of window to hide the toolbar
3.

Actual Results:  
The toolbar AND all visible, but background tabs disappear UNTIL the toolbar is
shown once again by clicking on the button in the top-right of the window.

Expected Results:  
The toolbar should have been hidden (as per OS X convention) BUT the tabs should
have remained visible to allow the user to select different tabs. Tabs are
*always* useful whereas the toolbar is (to me) less critical.

Camino 0.7 (nightly build January 17/2004) does this properly.

Comment 1

[Mike Connor [:mconnor]]

can you try a recent build of Firebird to test this? 
http://mozilla.oregonstate.edu/pub/mozilla.org/firebird/nightly/latest-trunk/Firebird-mac.dmg.gz
is the latest OS X nightly (01/18 already up)

Comment 2

[Eric D.]

Dear Mike Connor, the "bug" (more like quirk since FireBird doesn't crash b/c of
it) is still present in the latest build as of 20/January/2004 of FireBird
(Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040120
Firebird/0.8.0+).

It is possible to get something similar to the expected behaviour (that the tabs
are ALWAYS visible when more than one tab is open) by hiding "Navigation
Toolbars" however this defeats the foremost principle in good GUI design -- keep
things consistent (and, us Mac users are very picky about our interface ;).

FireBird is coming along nicely compared to build 0.5 that I played with on a
Windoze machine (of course, it was Windoze so that may be why it wasn't that
good ;).

Comment 3

[Jonathan Louie]

i'm seeing this behavior, although honestly i don't know why that button is
there at all.  safari doesn't have that button.

i'll bet that this isn't a bug, however, because seamonkey behaves the same way
(tabs are hidden).

Comment 4

[Hiro]

This bug was checked by firefox created from FIREBIRD_0_8_BRANCH.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.6) Gecko/20040210
Firefox/0.8

And in Camino, A tab bar and a bookmark bar are displayed.
I think that the same thing as this is good also at firefox.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7a) Gecko/20040219
Camino/0.7+

Comment 5

[Asaf Romano (gone)]

CCing Javier

Comment 6

[Emanuele Vulcano]

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; it-IT; rv:1.7.5)
Gecko/20041108 Firefox/1.0

Apple's Human Interface Guidelines state that, if a window has a toolbar and
shows a toolbar control button in the upper right part of the window, as Firefox
does, the toolbar's visible status should be toggled by clicking that button. It
is conventional among well-behaved Mac OS X applications that window content
which is necessary for operating the program is not hidden or displayed along
with the toolbar when clicking on a toolbar control button.

Clicking on the toolbar control button in Firefox hides the toolbar
successfully, but also removes the tab bar at the top of the window, which is by
consensus the fastest way to switch between tabs (the only other way to switch
is by using the very un-Mac-like ctrl-tab and ctrl-shift-tab keys). All other
browsers available for Mac OS X allow switching among tabs when a toolbar isn't
showing (for instance, Safari shows the tab bar when multiple tabs are open even
if all other UI elements are disabled; Camino doesn't hide the tab bar when
clicking the toolbar control button; OmniWeb doesn't hide the tab drawer when
clicking the toolbar control button).

This bug is always reproducible and is still in Firefox 1.0 final. (And yes, it
IS a bug, or at least a very major annoyance.)

Comment 7

[Matt Huggins]

I have a comment that may need to be moved to a new bug thread, but the effects
of the bug are similar to the effects of this one.

In WinXP, if clicking on a link that opens in a new window without the toolbar,
tabs are not displayed.  However, within the tab-less window, I can still open
up links in new tabs, which leaves the tabs hidden.  The only way to switch
among tabs is by pressing Ctrl+Tab on the keyboard, and you must already know
that there are other tabs open to switch.

I am using WinXP and Firefox 1.0 -- the exact version details from the About
window as follows:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-USrv:1.7.5) Gecko/20041107 Firefox/1.0

Comment 8

[Errol Smith]

This is related to (or maybe a dupe or dependency of) bug 243893. If that bug is
fixed, it might fix this bug also, because the visibility of the tabbar will
then be separated from the visibility of the toolbar/locationbar.
The behaviour in comment 7 is certainly bug 243893.
See also mozilla suite/seamonkey bug 143866 which has a patch about to land.

Comment 9

[Asaf Romano (gone)]

nsWebShellWindow::Toolbar() hides every chrome widget which is defined as
"chromeclass-toolbar", which is OK.

In order to fix this behavior, we have to remove the chromeclass-toolbar
definfintion of the tabbrowser widget and replace it with...something else,
maybe chromeclass-extra? How would it affect window.open(...toolbar=no..)?

Comment 10

[Asaf Romano (gone)]

Ian's patch on bug 143866 should fix it (s/xpfe/toolkit|browser).

Comment 11

[Asaf Romano (gone)]

fixed by bug 243893.