Open Bug 47873 Opened 24 years ago Updated 2 years ago

collapsed toolbars are indistinguishable

Categories

(Core :: XUL, enhancement, P3)

enhancement

Tracking

()

REOPENED
Future

People

(Reporter: davidhj, Unassigned)

References

Details

I have all toolbars collapsed and now, when I want to open say the Personal
Toolbar, I have to guess which is which because the handles both look the same.

A solution would be to differentiate them visually, e.g. by colour or by the
width of the collapsed handle.

This would also be useful when collapsing toolbars in order to rearrange them
(the "unintended feature" mentioned in 37766).
Severity: normal → enhancement
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
OS: Linux → All
Resolution: --- → INVALID
The tooltips that appear when you mouseover the collapsed handle indicate which
toolbar it is. In addition, the width of each handle is also different.

The "unintended feature" that you refer to never stayed in the trunk - it was a
result of the M16 branch.

Marking invalid.The tooltips that appear when you mouseover the collapsed handle
indicate which toolbar it is. In addition, the width of each handle is also
different.

The "unintended feature" that you refer to never stayed in the trunk - it was a
result of the M16 branch.

Marking invalid.
Actually, David makes a valid point.  Tooltips are only a stop-gap measure 
for making the collapsed toolbars distinguishable.  They are not an 
acceptable solution in the long-term because they require the user to 
hover over each toolbar in turn to find the one they want.

Overall, the collapsing toolbar mechanism needs a serious overhaul.  
They weren't effective in 4.x and they're no better now.  Reopening and 
marking Future so we can track the issue and resolve it later.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Target Milestone: --- → Future
Brendan you still left this unconfirmed? I'm assuming by error, marking 
confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually, I meant to accept it.  Thanks for pointing that out.
Status: NEW → ASSIGNED
I'm gradually coming to the conclusion that allowing the collapsing of toolbars 
at all is more trouble than it's worth.
Well, it is rather odd that there are two ways to get rid of toolbars: 1. collapse them and 2. deselect them via the View Menu. Why
not just have a right-click context menu on the toolbars which lets you select or deselect them. This is what e.g. Word does and it 
works pretty well as a compromise.
Severity: enhancement → blocker
Component: User Interface: Design Feedback → ActiveX Wrapper
Priority: P3 → P1
Hardware: PC → All
Target Milestone: Future → ---
* Nothing to do with the ActiveX wrapper. Changing back.
* Priority is for the use of the programmer who is fixing the bug. Changing back.
* Definitely not a blocker. Does not prevent normal use of Mozilla, or even cause
  data loss. Changing back.
Severity: blocker → normal
Component: ActiveX Wrapper → User Interface: Design Feedback
Priority: P1 → P3
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Status: ASSIGNED → NEW
Marking Future.  This toolbar design needs work, but it is too late to take on 
for this round.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: ASSIGNED → NEW
*** Bug 169160 has been marked as a duplicate of this bug. ***
Assignee: mpt → jaggernaut
Component: User Interface Design → XP Toolkit/Widgets
QA Contact: zach → jrgm
.
.
Status: NEW → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → WONTFIX
.
Status: RESOLVED → VERIFIED
toolbars are back, which I guess mean this is back too..
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
*** Bug 192852 has been marked as a duplicate of this bug. ***
I don't really think the idea of collapsed toolbars being collored or different
widths is the best solution to the problem. With these solutions the user would
have to remember width/color corrispondes with which toolbar. IMO, a better
solution would be icons  or text labels would be a better solution.
*** Bug 191973 has been marked as a duplicate of this bug. ***
As it is now, the bars are in the order they were collapsed, that is if I
collapse personal first, then menubar, then navigation, thats the order the tabs
will be in.

A better way (in my opinion) would be to keep the collapsed bars in order, so
that the menubar always comes first (if it is collapsed), then navigation, then
personal, no matter which was collapsed first.

Assignee: jag → nobody
QA Contact: jrgmorrison → xptoolkit.widgets
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.