bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Don't hide tab "bar" when OS X toolbar widget pressed

RESOLVED DUPLICATE of bug 150162

Status

()

Core
XUL
RESOLVED DUPLICATE of bug 150162
16 years ago
10 years ago

People

(Reporter: fillup, Assigned: David Hyatt)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
This is a feature request for Mac OS X Mozilla.

When collapsing the toolbar at the top of the browser window by using the Mac OS
X toolbar collapse widget, the status bar also collapses, leaving a pure
browsing window with a thin frame.  While this may be desirable in many
situations (screenshotting, etc.), I find that for my day-to-day browsing, while
I prefer collapsed-mode (and just using keyboard and/or mouse to navigate
without buttons/addresses), I would also like an option to be able to retain the
status bar (IE 5.x for Mac does this, for example).  Would allow you to see the
targets of links, loading status, secure symbol, etc.

This is especially true on my laptop, where I have limited vertical real estate
due to screen size and the use of a bottom-edged Dock.

Again, this is a feature request at the level of "it would be nice for me
personally, and I think it would be nice for others, but maybe I'm just weird."
(Reporter)

Comment 1

16 years ago
I'm sorry, I had debated on filing a second enhancement request for a related
issue, but now I think I should just add it here.

Related: when collapsing the toolbar, the tabs for tabbed browsing should also
remain (should be set by a user preference or setting).  Again, you can retain
the nice, pretty screenshotting / real-estate reasons for collapsing the
toolbar, but retain some functionality.  I would encourage anyone to play with
the toolbar settings in IE 5 on the mac for comparison.

In IE, the "collapse toolbar" command and widget are basically toggles between
two user-defined states.  One is usually the "full" state, with buttons, text,
address bar, personal link toolbar, status bar, etc. etc. etc.  The other state
**defaults** to be just like mozilla, in other words, when you collapse, all the
toolbars go away.  But if you turn on one toolbar or another (like the status
bar, for example) while in this "empty" state, it will remember this the next
time you switch to this state.

Comment 2

16 years ago
Actually, file that second comment as a bug. It's a different issue, and I think
it's actually a serious bug, since it bars a user from using tabs when the hide
toolbar widget is used (unless (s)he knows keyboard shortcuts). 

The first issue you had is a matter of preference (and does not take away from
usability), so chances are that the second issue will probably be fixed more
quickly than the first. 

BTW, as a workaround for your first issue, if you want to hide everything but
the status bar, go to the View menu, choose Show/Hide, and Click on Navigation
Toolbar and Personal Toolbar.

Updated

16 years ago
Depends on: 128678

Comment 3

16 years ago
Prachi is right. Your first request is best handled by selecting which toolbars
to hide using the menu. The toolbar widget should hide all toolbars, which is
what it should do.

Your second request is more important. Tabs should not be hidden by the toolbar
widget since it leaves no means to move among them. All other toolbars have menu
accessibility. (There is another bug open somewhere suggesting a "Tab" menu to
accompany the "Window" menu. If something like that were done, this bug wouldn't
be necessary.)

Confirming, editing Summary, raising Severity to Normal, and reassigning to XP
Toolkit/Widgets: XUL.
Assignee: mpt → hyatt
Severity: enhancement → normal
Component: User Interface Design → XP Toolkit/Widgets: XUL
QA Contact: zach → shrir
Summary: Collapsing toolbar on OS X should leave status bar → Don't hide tab "bar" when OS X toolbar widget pressed

Comment 4

16 years ago
See bug 152084 for related discussion.
(Reporter)

Comment 5

16 years ago
(I'm the reporter, just an "average joe").

I guess I see what you're saying about the first issue (I can work around it by
using two menu options), although as a user I heartily disagree that the two
issues should be separate.  I really **like** the Mac IE behavior in this case
(in fact, I wish all browsers had an on/off toggle for toolbar states).  I think
the toggle should be a genuine toggle between different states, not just a "hide
everything" button. 

Using one menu option (off a secondary menu) and then another menu option (again
off a secondary menu) to accomplish MY desired browsing experience is more than
a bit annoying and is not really an acceptable workaround for me.  My personal
opinion on usability is that it's not okay to just say "oh yeah, use these seven
menu options in place of the behavior you actually want in one click that
another product gives you.  That's why the seven menu options are there."  But I
am clearly outvoted on this one ;)  so I submit it as my respectful opinion on
the usability of Mozilla as a daily substitute for me personally.  No hard
feelings :)

I do agree however, that the second problem is more important, since it pretty
much makes the toggle almost completely useless for me, as I am a
tabbed-browsing fanatic as well.

Comment 6

16 years ago
Somewhere along the line this bug appears to have become unconfirmed again.
Reconfirming on the basis of comments that we're addressing the fact that the
tab bar disappears and shouldn't. The reporter makes a good case for addressing
the rest, but I feel that portion should be re-raised as a separate enhancement
request.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

16 years ago
Tab bar collapse is a dupe of bug 150162.

Comment 8

16 years ago

*** This bug has been marked as a duplicate of 150162 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.