Closed Bug 112534 Opened 23 years ago Closed 17 years ago

Remove collapse toolbar grippies

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: djm, Assigned: janv)

References

Details

(Keywords: polish, Whiteboard: Please don't comment with arguments, just vote. See comment 8 to turn them off.)

Attachments

(6 files, 4 obsolete files)

It would be good if there were some way to disable the toolbar collapse
grippies. I find them annoying (never having found a use for them) and some less
computer literate people I know have found them very confusing ("where's my back
button gone?"). 

Some pref (or skin hack) to disable them entirely would be greatly appreciated.
Status: UNCONFIRMED → NEW
Ever confirmed: true
fwiw ie6 appears to have something like this.
(I played around with PhotoShop (see attachment) and think that Mozilla would
look even cooler without the grippies :)

I recently installed IE 6.0 to see how they're doing and really liked the new,
grippieless look. I've always found the Netscape-style click-to-collapse
grippies confusing, and there should definitely be a pref to disable them.
Please.
I made a really simple patch that disables toolbar collapsing. You are still
allowed to uncollapse collapsed toolbars, though. It removes two lines from
chrome\content\global\bindings\toolbar.xml (line 262, in toolkit.jar).
Reporter: does the patch make you happy? Probably not. In other words, is this
bug about making clicking the grippies not collapse the toolbars, or about
hiding the grippies altogether? Probably later, but I think it could be read
either way (the title should probably be reworded). I think there should be a
bug for both cases. Which one this is?

The grippies are not "collapse grippies", think of them as "handles" that can be
used to drag the toolbars into a new place. This is rarely needed, unless you're
a "power user". Also, inexperienced users often accidentally click or drag the
grippies and do stuff they can't undo without assistance, which is the reason
Microsoft (finally) added the feature to lock the toolbars (hide the grippies)
in IE 6. And they turned it on by default.

The grippies also have a weird side-effect (pretty much in Netscape and Mozilla
only, if I'm not wrong) that when they're clicked, they collapse the toolbar.
This, of course, is very confusing to users that aren't used to this behaviour.

Bug 15322, toolbar movement, targeted for Mozilla 1.2, is still not fixed (and
won't be for a while, I'm sure), which means that the grippies are more or less
useless since the toolbars cannot be moved.

I'm proposing the "useless-ui" keyword, since the mozilla 1.0 manifesto
(http://www.mozilla.org/roadmap/mozilla-1.0.html) says that every ui element
must do something useful.
beware: do NOT apply this patch if one or more of your toolbars are collapsed
(they become hidden and can't be uncollapsed). This is a really ugly hack but
it mozilla plenty pretty makes. This patch basically removes a section
(<binding id="toolbargrippy" etc.) from the toolbar.xml file. I don't know how
to do the fix properly but this works. Kind of.
In <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=65067>, I specify 
that the bars should no longer have grippies, at all. They cause a host of UI 
problems, including lack of distinction between multiple collapsed bars, 
ugliness of collapsed state, ugliness of expanded state (which is what this bug 
is complaining about), and difficulty of cancelling a toolbar drag (since a 
non-drag click collapses the bar instead of doing nothing).

However, the grippies should not be removed until the bars have a shortcut menu 
to make them easy to turn on and off, as shown in the `Chrome area shortcut 
menus' section of the spec.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
OS: Linux → All
QA Contact: zach → sairuh
Hardware: PC → All
Summary: Way to disable collapse grippies → Remove collapse grippies
Attachment #68808 - Attachment is obsolete: true
Attachment #68818 - Attachment is obsolete: true
I marked my ugly and silly patches obsolete. Please don't use them :)

While waiting for a real fix for this, you can use this nice workaround:
Add these lines to userChrome.css in your profile's chrome directory

toolbargrippy
{
    display: none !important;
}

This will disable the grippies (taken from
http://www.geocities.com/pratiksolanki/userChrome.html)
Target Milestone: --- → mozilla1.1beta
Yes, we should definitely remove the grippies.  A mechanism needs to be in place
to automatically uncollapse any toolbars that the user had collapsed.  Patches,
anyone?
Keywords: helpwanted
Nominating for buffy, this fits the polish/usability improvements criteria well.
 Our usability studies showed that users thought this was for a variety of
functions other than collapsing, such as showing icons only (no text) in the
toolbars.  This collapsing functionality is not useful, anyway.
Keywords: nsbeta1
It is my understanding that while usability studies can help identify problems
in the interface they do not count as a representative sample of our target
audience.

Nav triage team: CC'ing Lori regarding usability study findings Blake mentions.
Whiteboard: [need info]
I don't know if it's representative of everyone or not.  I haven't heard a case
for why the ability to collapse toolbars is in any way useful.
In the absence of an IE-like way to stack or edit the toolbars, they are IMO
completely useless. The ability to hide a toolbar is already (and more usably)
provided in the menus.

Can anyone make a case _for_ the grippies?
<http://portal.acm.org/citation.cfm?id=274657> presumably makes a case for them.
I don't know what the paper says, since I'm not an ACM member, but I doubt it
would change my mind. :-)

Fixing this bug would resolve bug 47873, bug 48332, bug 50785, bug 57022, bug
89199, and bug 103515.
Keywords: polish
I've read the paper, and it goes through a number of alternatives (quite scary,
to be honest, including vertically and horizontally-*tabbed* toolbars) and
reaching this design at the end. It seems from the tone of it they were rushed
because of a short development cycle and did not do any formal user testing
until reaching the final design, which is the collapsable-grippy model.

They say two important things about it: that the collapsed grippy's size was
essential to the user discovering what toolbar it corresponded to, and that they
needed to change colour and mouse shape on mousing over to suggest it was
clickable (Mozilla breaks the first suggestion by providing the same size of
grippy for any toolbar, and the second by not changing mouse icon, and IMO those
are not good solutions to their problems, to begin with!)

I am quite sure that anyone reading this document will entertain a notion of
dislike for the features and the process they were designed through. I'd
advocate removing this unusable feature from Mozilla, and implementing a proper
solution (instead of a half-designed one) for toolbar size reduction. For now,
the view menu will more than suffice for what is being asked for.
I omitted an important remark: that the design was produced for Netscape 3.0,
and that the designers describe their target audience as business users using
laptops or 14" CRTs at 640x480 pixels.
Attached patch patch (obsolete) — Splinter Review
Attachment #93112 - Flags: review+
Comment on attachment 93112 [details] [diff] [review]
patch

Well, for the lot of bloody good it does you, r=FrodoB. :)
Comment on attachment 93112 [details] [diff] [review]
patch

>+++ classic/global/win/toolbar.css  28 Jul 2002 23:07:37 -0000
>@@ -54,53 +54,6 @@
> 
> /* ::::: toolbargrippy ::::: */
> 
>-toolbargrippy {

you missed a spot ;-b
Whiteboard: [need info] → [need info][geekweb-p1]
my vote: just delete them entirely (for now and the foreseeable future). If at
some point, toolbars are customisable and draggable, then turn them back on,
BUT, only as dragging, and only when users select the "allow me to play with my
toolbars" preference. Collapsing is **************** useless and really
annoying! I keep hitting them when I'm aiming for the menu or button. Thanks...
Attached patch up to date patch (obsolete) — Splinter Review
Attachment #93112 - Attachment is obsolete: true
Comment on attachment 101522 [details] [diff] [review]
up to date patch

This patch only appears to address 37 of the 55 occurrances of toolbargrippy in
lxr seamonkey tree.
thanks Neil, I'll attach a new patch
Attached patch better oneSplinter Review
I hope, this covers whole tree
Attachment #101522 - Attachment is obsolete: true
Attachment #101540 - Flags: superreview+
Comment on attachment 101540 [details] [diff] [review]
better one

yay. sr=me
So, talk to the mail/news and editor people and see if they're okay with
removing the toolbar collapse grippies. You have my blessing, but we'll need to
figure out a way to work around the profiles for which the toolbars are
currently collapsed.
Bugs possibly affected by this :

bug 12267
bug 48332
bug 50114
bug 50785
bug 60864
bug 128963 ?
bug 130184
bug 135342 and bug 150162 (?)
bug 167406

Apply it ! Apply it ! :)
we can also remove grippytooltiptext later
I sortof liked them, but I can understand how they would confuse many novices.
It's certainly ok with me (for Composer) if the the conclusion is to simplify
and remove them.
> we'll need to figure out a way to work around the profiles for which the
> toolbars are currently collapsed.

Change goToggleToolbar?
neil, goToggleToolbar uses hidden attribute
grippies use moz-collapsed
"we'll need to figure out a way to work around the profiles for which the
toolbars are currently collapsed."

has that been figured out yet?
Jag suggested for example to remove moz-collapsed from toolbar element in its
binding ctor.

We can also add a cleanup funtion to xpinstall to remove moz-collapsed
occurences from localstore.rdf (but how to deal with multiple profiles ?)

And I just found out that we can remove moz-collapsed from xul.css entirely so
even if there is such element with this attribute set, it won't get collapsed.
It just needs to fix fullscreen.js, since it uses moz-collapsed attribute too.
mailnews team is ok with this fix too
jglick and mailnews module owners are on board.
Jan: one last thing: grippyhidden and grippytooltiptext attributes and entities?
my plan is to land core changes first and then remove these attributes and entities
Comment on attachment 101717 [details] [diff] [review]
patch to remove moz-collapsed

r=caillon
Attachment #101717 - Flags: review+
Comment on attachment 101540 [details] [diff] [review]
better one

Man, I actually grippy collapse quite often (quicker than View > Show/Hide >
...)

I wonder how many times I'll click over there with nothing happening... Oh
well.  r=caillon.
Attachment #101540 - Flags: review+
Comment on attachment 101665 [details] [diff] [review]
additional patch for mailnews

r=caillon.
Attachment #101665 - Flags: review+
patches have been checked in

perf wins:
Txul: 2-3%
Ts: 1-2%
If it's not too late, please consider leaving a non-displayed box with image in
the grippies replacement (giving it some meaningful ID.) The Sky Pilot theme
(perhaps others?) used the grippy background (in conjunction with
#throbber-box) as toolbar end-caps to give the toolbar a unique look.
On further thought, only a box with an ID is needed since I could accomplish
this same effect with a background-image statement; rather than a
list-style-image statement.
Please ignore my last comment #45 and Comment #46, I've figured a way around the
problem.
Patrick: You said you already found a way - nevertheless I want to remark that
it's easily done with a bit of XBL magic as I used it LCARStrek theme (for end
caps at the right, I think now I also must add them at the left) ;-)
Hi Robert, I was able to use #throbber-box for the right-hand end-caps. For the
left, I ended up moving the toolbar background from ".toolbar-primary-holder" to
".toolbar-button-box", throw in some margin adjusts for the mast icon and
.toolbar-primary-holder (depending on if the icon was displayed) and finally
using .toolbar-primary-holder for the left end-caps. I say end-caps since they
are different depending on [toolbarmode="small"] (navigator full screen) and
[buttonstyle="text"/"pictures"] (new primary toolbar button modes.)

Caveat: I also had to dork around with some of the other component
.toolbar-primary-holder settings (specifically, navigator.css and help.css) but
I think it would too detailed to list here. I can send you the changes if you
want to take a look-see?

Lastly, thanks for looking out for my backside. I have made binding changes
before (tab toolbar and sidebar) but tend to seek other ways, if possible, so as
to reduce down-stream maintenance problems.
Joonas: The IE Grippies DO APPEAR by default on all news installations of Win98,
2000, ME and XP. So your argument is based on a wrong assumption.

When you installed IE 6.0, you probably already had the pref set in your
registry that's why it installed with the grippies invisible.

Try formatting your computer first before installing windows and you will see
that the grippies do appear.

Personally I am not in favor of this bug. Instead of removing them, we should
work to make them work as expected: to be able to drag toolbars around.
Sorry, didn't mean to spread disinformation. However, I'm sure that the module
owners et al. didn't make the decision to remove the grippies because I claimed 
that IE hides them by default, but because they thought the grippies were 
confusing to users.
-> me
Assignee: blaker → varga
Moz looks much better with them removed. I don't see much point in worrying
about a pref until they actually do something useful, like rearrange the
toolbars. And then it should be in the context menu.
I started up my nightly automated install of Mozilla today, and noticed
something "not right" with the toolbars, but I couldn't put my finger on it
until I delved into bonsai...

While I think the UI looks nicer without them, and I admit that I (and most
others) used them rarely, there is one slight problem

There is now no way to hide the menu bar (err, collapse it). The menu bar is the
only toolbar without an entry in View > Show/Hide, and it should still be
collapsable. 

(I set up a kiosk with a non-fullscreen mozilla with the menu bar collapsed at
my work. It was, at the time, very useful.... not secure in the least, but it
kept everything hidden while still leaving space for other programs on the same
screen.)

I guess I can just go in and add some lines to my user.css to do the same thing,
but I thought I'd mention it.
if this stays fixed, we should purge the tree of any toolbar grippy tooltips 
from the various .dtd files, too.
about full screen, yes, now with out the toolbar grippies we can't hide / show 
them toolbars whe in full screen.

but I was able to go out of full screen, hide / show what I wanted, and then go 
back into full screen.

that seems acceptable to me.

I hope the grippy removal stays.  what are the points against?
here are the bugs i see in
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021008
[classic skin]
1. you can't show/hide the toolbars in venkman/inspector
2. when maximized, the file (ie first) menu appears displaced (perhaps by about
one grippy width?)
3. the menubar is too tall [1-3px] (since it behaves like notepad its height
should match), it should bleed into top of the window instead of having a bevel.

some other things are probably just generic ancient bugs (or relate to me
putting my sidebar on the right side):
A. the quick search in address book bleeds into the left window border
B. the quick search in mailnews bleeds into the (think) right window border
C. the tabs area in navigator bleeds into the right window border

Actually A-C might change (basically reverse which border i'm complaining about)
if we fix:
4. there shouldn't be a left/right borders for the menubar
     i.o.w. it *should* bleed into the window border, as notepad does
     perhaps a better example is wordpad since it has toolbars and a menubar and
no grippies.  the toolbars should all bleed right into the border.
5. alt-space, right still doesn't work (dean has a patch, why doesn't someone sr
it?)
Is there any chance this bug could be modified? Some sort of hidden pref for
those of us who liked the grippies?  I personally, due to a very small computer
room setup, don't have a large monitor and use the grippies all the time to get
a little more real estate. Buying a larger monitor to run at a higher resolution
is a bit of a pipe dream right now.  I understand they are somewhat
non-standard, but once you learn what they do, they are *very* nice and honestly
one of the reasons I have liked Mozilla for so long.

I admit a general unfamiliarity with how things work around here (I've
filed/commented on a few bugs, nothing much) so I obviously can't raise much of
a stink. But I really do like the grippies, I use them a lot.  Perhaps a tool
tip could be added if the mouse hovered over the grippies? ("This will collapse
the toolbar to free up browser space."?)

Please reconsider! If I had a 19" monitor I wouldn't care... but I don't, so I do.
jmscott42: 

a) You can turn off all but the menubar using the View menu, so it isn't too
harsh a regression. 
b) The grippies *did* have tooltips; however, tooltips are a bad solution to the
inherent discoverability problem the grippies have. I myself was very annoyed
every time I collapsed them and had to restore a specific one.
c) The vast majority of users doesn't appreciate the tooltips, and think
something is broken when they click by mistake on them (notice how close to the
back button the middle one was)

I sympathize with you as I used the grippies many times to do presentations
using Mozilla. But this is too much a usability problem to be kept in. Somebody
can code an XPI that adds them instead.
Anyone mind if I add my $.02?  If you want to remove it, fine, just please add a
preference somewhere (and make it obvious for all us dumb people) where we can
get them back.  

I don't particularly like the full-screen mode, I think that the grippies were a
damn good idea (I run with only one bar up normally - personal shortcuts, and if
I need something I'll unhide the grippy - everything else stays hidden...), and
I'm probably going to revert to an older version so I can get them back. 

I like a nice lean browser, real-estate wise, and I just don't like the full
screen mode (if I want to use the taskbar at all, I have to hit the Windows key
to bring it up, and then click a couple of times to get rid of it- a little too
much effort just to find out the frickin time).  Personally, it is a rather
harsh regression, so I'd like to see it stay.  Leave it off as standard, but
give us a preference window somewhere for it.  

Just because it's not liked universally, doesn't mean it has to be expunged from
Mozilla.  Set it up as a pref somewhere.
Re: Comment #60 From michael_bourgon@yahoo.com 2002-10-12 09:56
> If you want to remove it, fine, just please add a
> preference somewhere (and make it obvious for all us dumb people) where we can
> get them back.  

While we're at it, why don't we add a pref to behave like IE? Yeah? No? Why not?

*yawns*

We have *way* too many prefs right now. A pref to add the toolbar grippies back is a *
stupid* thing.

An XPI to add the functionality back in is fine though.

> I don't particularly like the full-screen mode,

What does that have to do with this?

> I think that the grippies were a
> damn good idea (I run with only one bar up normally - personal shortcuts, and if
> I need something I'll unhide the grippy - everything else stays hidden...), and
> I'm probably going to revert to an older version so I can get them back. 

Just go to the View menu, "Show/Hide", and show or hide what bar you want shown or... 
er... hidden.

> I like a nice lean browser, real-estate wise,

Mozilla is not a lean browser. Try Phoenix. Or K-Meleon.

> and I just don't like the full
> screen mode

I heard that.

> (if I want to use the taskbar at all, I have to hit the Windows key
> to bring it up, and then click a couple of times to get rid of it- a little too
> much effort just to find out the frickin time).

Um. That's not quite a Mozilla issue.

> Personally, it is a rather
> harsh regression,

It was a regression that grippies were ever thought of.

> so I'd like to see it stay.  Leave it off as standard, but
> give us a preference window somewhere for it.  

This is a feature a tiny minority needs - or thinks it needs it. Therefore, it shouldn't be 
anything more than an XPI-based add-on.
> just please add a preference somewhere

A feature used by 0.01% or less of our userbase isn't worth the XUL bloat to
keep it in as a pref. Eaither write an XPI you can install on your own builds, or...

Perhaps some more of the entries in the show/hide menu need hotkeys? That would
be of more general use, less confusing for other users, and satify your need to
often toggle of bars on and off. F4 & F5 for navigation and PT bar maybe?
Re: Comment #62 From Jeremy M. Dolan 2002-10-12 12:43
> F5 for PT bar

F5 is common for "refresh" on Win32.
grippies were added due to usability testing data collected in the 4.0
timeframe. They were needed then and they are still needed and used now by many
people, not a small minority. We still see usage in usability and have other
usage data. This is a serious usability regression and will hurt a large part of
the Netscape user base , which constitutes a large majority of the Mozilla user
base. 

I'm not sure what usability data Blake is referring to. If it was the data from
studies this summer, they did not show confusion about toolbar buttons. 

People use grippies to temporarily collapse toolbars when they need to maximize
screen real estate and when they don't want to be bothered with features but
want quick access to them. In terms of the confusion of collapsed state of
stickies, that was tested too and tooltips fixed any issues that existed.

Full screen mode and menu access are not sufficient replacements for this
feature. Grippies need to come back and not as a pref. We _do_ have too many prefs. 
I cannot imagine what usability data you must be collecting, but my experience
with toolbar grippies has been universally negative. The two novice users who I
introduced to Mozilla (from IE) both required my assistance to unhide their
toolbars after miss-clicking buttons on it. 

When I showed them what went wrong,  their reaction was (in each case) confusion
- they had found the show/hide toolbar menu and played with it to no avail.

The problems with the toolbar grippies are:

1. They are too easy to hit
2. Their function is not clear
3. They look like toolbar grab-boxes for detachable toolbars (which Moz doesn't
yet support)
4. They duplicate a function (show/hide toolbars) provided elsewhere in the UI

I agree that show/hide toolbars should be easy to use (e.g. should have keyboard
accelerators assigned). Fixing show/hide (in a separate bug) would be much more
usable than retaining these UI horrors.
> grippies were added due to usability testing data collected in the 4.0
> timeframe. 

This is incorrect. Grippies were added due to usability testing collected in the
*3.0 timeframe*, and I seriously question the usability process they used to
choose this  functionality. This has been stated before in the bug (back in
comment 15).

(I have a PDF version of the original document by Irene Au and Shuang li
published in the CHI 98 proceedings that I can't publically post due to ACM
copyright restrictions, but I offer to send it to interested researchers if they
contact me through email.)

> They were needed then and they are still needed and used now by many
> people, not a small minority. We still see usage in usability and have other

Usage in usability?

> usage data. This is a serious usability regression and will hurt a large 
> part of

No, it was bad design, and its removal has already started helping our user
base, since end-users (including my parents, which were two Netscape customers,
and today run Mozilla) commonly have problems using the grippies. The problems
with them have been hashed out before here and in other places. 

> the Netscape user base , which constitutes a large majority of the Mozilla 
> user base. 

I honestly suggest serious usability testing be done on the Netscape
Communicator product if you believe grippies are still a good idea in a
end-user, commercial, browser. And, at any rate, Netscape can add grippies in
their Communicator XUL if they choose to intentionally harm their users.

Let's not make improving Mozilla's UI impossible; it already is hard enough.

Re-resolving FIXED. Please, let's take the discussion to the newsgroups, no
sense in spamming innocents here.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
QA Contact: sairuh → claudius
Summary: Remove collapse grippies → Remove collapse toolbar grippies
Blocks: 175078
discussion should indeed be in the newsgroups.

just for reference - a couple of bugs have been filed about the missing grippies
already - i've duped one to the other, and marked that WONTFIX following the
discussion here. it's bug 175091.
I went back from 1.2beta to Mozilla 1.0.1 because of the grpippies. Don't take
away the grippies! (At least, how do I get them back? Is there a line in the
Preferences .JS files or anything to enable them on 1.2beta?)

I think, a lot of users like the grippies as a distinct feature of
Mozilla/Netscape. It doesn't have to be every bit like MS IE! BTW, if you like
"copying", copy from Alias/Wavefront Maya! This high-end 3D design application,
originally created for SGI Irix workstations, has grippies just like Mozilla.
Re: Comment #68 From Eugene Scherba 2002-10-22 13:45

> I went back from 1.2beta to Mozilla 1.0.1 because of the grpippies.
> Don't take away the grippies!

That's not really an argument on why you want or need them back. Most likely not
because they look nice?

> (At least, how do I get them back? Is there a line in the
> Preferences .JS files or anything to enable them on 1.2beta?)

This is the wrong place to ask.

> I think, a lot of users like the grippies as a distinct feature of
> Mozilla/Netscape.

They were there because Netscape 4 had them. Netscape 4 had them because they
were a - for that time - interesting way of moving around toolbars, and
collapsing them.

We're now in 2002, and collapsing toolbars no longer makes sense. We have
"show/hide" in the View menu for that already.

Moving around toolbars does not work in the first place. Until this is changed,
there's no point in grippies for Mozilla.

> It doesn't have to be every bit like MS IE!

This is Sooooo not about MS IE. MS IE, btw, *does* have grippies. Only that you
can turn them off since version 6/Win32.

> BTW, if you like "copying", copy from Alias/Wavefront Maya!

Yeah, cuz' a very-high-end 3d application is quite similar to a web browser when
it comes to the interface / front-end. Uh-huh.

> originally created for SGI Irix workstations, has grippies just like Mozilla.

There are other programs who also do. Like MS Office. But that's totally besides
the point.

Unless you tell us what exactly you're missing, grippies aren't going to return.
Whiteboard: [need info][geekweb-p1] → [need info] BEFORE COMMENTING, READ COMMENT 69!
> Unless you tell us what exactly you're missing, grippies aren't going to return.

I guess, I have to tell you that in clear terms. I am missing an interesting and
DISTINCT way of moving around toolbars. Do you get my point?
Re: Comment #70 From Eugene Scherba 2002-10-23 10:56

> I am missing an interesting and
> DISTINCT way of moving around toolbars. Do you get my point?

Yes, I do now. But as I already pointed out, there was never a way to move
around toolbars in the first place, in Mozilla. That feature is still being
worked on, and until it's done, there is no reason for grippies to return.
I see. I will rephrase my plea: I am missing an interesting and
DISTINCT way of COLLAPSING toolbars. Who needs moving tollbars?
OK! I now know that insanity and mob rule govern the mozilla application
framework. Why would you want to break apps that third party devolpers are
making or have made. toolbar grippies are usefull. Why would you want to remove
this from the toolkit, toolbars.xml, just because the apps that mozill.org build
using them suffer from usability issues - fix those apps don't change the
toolkit. You can disable grippies, by not referencing then in xul and by styling
them, without removing the functionality and breaking third party apps by
removing this functionality from the toolkit. Is the point to drive developers
away from building apps based on mozilla? Is the stabilty of the toolkit less
important than than the few apps currently built by mozilla.org and their
usability issues? Are current and future apps to be hamstrung by a constanly
changing feature set in the toolkit? Is the idea to have developers constantly
reinventing the wheel? The arument 'if you don't like it make your own' and 'we
can't afford the xul bloat' smells - you are talking about a few lines of code.
My reading today of the toolbars.xml shows grippies are gone. I PLEAD FOR
SANITY. I PLEAD FOR STABILITY IN THE TOOLKIT.
This is not a bug. The grippies were removed by request of a few?!

Please restore them in future versions of Mozilla. They are very useful
because they enable the user to instantly toggle hide/view instead of having to
go to the view menu to hide/view - a much longer procedure.

Is IE the browser everyone dreams of?

At the very least, I suggest that a pref.js option be created so that power
users can restore the grippies while the less fortunate common users 
learn to live without.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
This was very much a bug. Fixing this one fixed at least 10 other ones, see
comment #28. Grippies are gone, and not ever coming back, at least not until we
have moveable toolbars. If you want a faster way to toggle view/hide, go open a
bug requesting a keyboard shortcut for it.
Status: RESOLVED → VERIFIED
That is already filed: bug 45532 
Please: If you want Moz to be as "convenient as IE" then go vote for bug 45532
which is about adding a context menu for toolbars - exactly what IE does. IE has
never had something like the collapsing grippies, as far as I know. 
you might want to put this in the release notes.
"The ability to hide a toolbar is already (and more usably)
provided in the menus."

I cannot disagree more!  If this were true, then why have toolbars in the first
place?  You could say this about EVERY function provided by the toolbar.  
Resorting to a menu is less efficient, which I relate to usability.  The grippie
is definately the most efficient way to hide/view toolbars.  Even a context
toolbar menu is less efficient than the grippie.

"target audience as business users using laptops or 14" CRTs at 640x480 pixels."

IMO the toolbars still eat a lot of real estate on a 12" notebook running
800x600 or a 13" notebook running 1024x768 with larger fonts.  AND, if I enter a
java app from a web page, I want to quickly minimize the toolbars.  When I leave
the java app, I want 'em back quickly.  There are lots of reasons to minimize
the toolbars.

"You can disable grippies, by not referencing then in xul and by styling
them, without removing the functionality and breaking third party apps by
removing this functionality from the toolkit."

I agree 100% with that.  Removing them from the toolkit sounds like solving the
"issue" with extreme prejudice.
I vote WONTFIX for this "bug".  Saying it will fix several others is a cop out.
I doesn't fix them, its just giving up.

grippies for collapsing the bars are useful.

"The ability to hide a toolbar is already (and more usably) provided in the menus."

I also disagree with this, wholeheartedly. As essentially stated in comment #80,
you might as well remove the bars altogether if you believe this bizarre argument.

If fixing the problems with grippy behavior is beyond your abilities, ask for
help, or just hide them by default & leave us who use them the option of
bringing them back. Are you planning on eliminating every feature that has bugs?
Might as well scrap the whole project.
"I cannot disagree more!  If this were true, then why have toolbars in the first
place?  You could say this about EVERY function provided by the toolbar."

Toolbars are designed to give rapid access to *frequently used functions*. Not
everything has to go in a toolbar.

The assumption going on here is that hiding/showing toolbars is not a frequently
used function, therefore it doesn't need rapid access (grippies). I guess some
people disagree and for them, the grippies are useful. However:

- grippies DON'T hide the toolbar. They still use up a significant chunk of real
estate, especially for a single collapsed bar.
- once collapsed, it is not obvious what they are or which one is which.
- many people accidentally click them and then cannot figure out what they have done

It would be possible to hide the grippies by default (I guess), but that then
requires another preference, and Mozilla already suffers from bloat in the
preferences, so developers are being very careful about adding more. Some power
users don't see this as a problem, but Mozilla is not just a browser for power
users! The more preferences, the more confusing options for casual users.

The concluding argument here, is that the grippies would be a lot *more* useful
if they could also be used to move the toolbar, and if that were done then
having a preference might be worth the trade off (like IE and the "lock
toolbars" menu item). That functionality, however, is a fair way off and in the
meantime it's not worth the tradeoff.

Please try and see it from all sides and not just your personal point of view.
Thanks
I never used grippies to hide toolbars because things like the personal toolbar
take up almost as much space collapsed as they do normally. If I really need
more room temporarily, I just hit f11. Easy. Even in 4.x which didn't offer
fullscreen on UNIX, I removed them in the menus.

I think Aaron did a great job summing up why they need to go. One more thing to
keep in mind though. Instead of bloating Mozilla by still supporting them with a
pref, you can always add the XUL/CSS back, or even the C++ code in necessary.
Moz is open source, and most of the UI is run-time compiled/applied. This is
great for those features (grippies) that one-in-a-million users (you) want.
A question: Will this "fix" be applied only on the 1.2x and later branches, or
will it be imposed on 1.0x and 1.1x?  Given the use of the feature in 3rd party
apps as mentioned in comment #73, I would encourage you to not apply it to the
earlier branches.
definetely not for 1.0
Just a note to the uninformed. Grippies were provided by the toolbox method of
the toolbar.xml. Grippies offered an area for a tooltip that was set aside from
the other tooltips that appear in toolbars to clearify the interface, a graphic
to set the bar apart from the rest of the interface and when wrapped in the
toolbox method they had the ability to be collapsed into the toolbox tray
holder. In any skin the collapable feature, bug, was not required to be used nor
was the tooltip or graphic area. Developers had a choice to use grippies or not.

The usage, implementation, of the grippy feature, bug, in the modern and classic
skin, was not so good and it is fine with me if grippies are not in those skins.
Instead of fixing those skins, by wrapping the toolbar and menubar in a vbox in
the navigator.xul and editing the toolbar.css in the modern and classic
packages, it was somehow decided to remove this functionality from the toolkit
completely. By fixing this 'bug' in the manner decided tooltips for menubars and
toolbars are pretty much useless. Now any, all, apps that used this feature are
broken - this includes skins and other xul apps that may have used this feature,
bug, in their interface. Now all the xul documentation is broken, including the
two published books. Instead of the mozilla.org developers needing to fix a few,
5 I believe, files they had to 'fix' many, many files - see comment #25 for a
partial list. Now all third party developers must either remove this
functionality from their interfaces or reimplement the toolbar.xml

If any third party developers that would like to include grippies in their
project they can contact me as I have a toolbar.xml that fixes some of the odd
behavior of the toolbar.xml. Watch kiosk.mozdev.org for a gtoolbar.xml soon. If
the mozilla.org developers would like to see a test case of no grippies in
mozilla-1.0.0 or the updated toolbar.xml or how to correctly use it you may also
contact me. I would like to see this functionality returned to the toolkit and
to the developer community - the real people hurt by this 'fix'. If you want to
flame me do it here please. I am sorry for this long comment but I feel no real
discussion, understanding, of the usage of grippies has occurred and many
missinformed assumptions have been made here. 
I would like to make the following comments/statements:

1) I still use NC 4.79 for mail/news due to its maturity and functionality.  The
term "grippy" or "grippies" is never used to refer to the "vertical tabs" found
on toolbars and window panes within this suite.

2) The "vertical tabs" have one purpose:  to collapse/hide a toolbar or window
pane with one click, and have it available again for a similar one click without
resorting to keyboard or menu access.  Toolbars in NC 4.79 are moved up/down by
left-click-hold on any portion of the toolbar in question.  Vertical tabs were
never intended for this purpose; this isn't their function.  I don't know how it
came to be thought that vertical tabs were designed as a "grip site" for dragging.

3) A mouse motion of one click = toolbar or window pane collapsed, or
uncollapsed, does not equate with the string of mouse motions going up to the
Menu Toolbar, clicking on View, sliding over to Show/Hide, and clicking on the
toolbar one wishes to show or hide.  There is definitely a time and mouse motion
difference between the two options, and the vertical tab method provides a
faster, more accessible functionality.

4) As a pleased user of Mozilla 1.1 browser, I am extremely disappointed by this
decision.  I feel it was made arbitrarily, without accurate, real-world feedback
on how the vertical tabs were used.  It was also made on faulty information as
to the primary function of vertical tabs, not to mention a gross misnomer of the
feature itself.

5) This "bug" only received 4 votes:  how did it come to garner so much
attention that put it among the front runners to be fixed for 1.2 final? 
Especially when there are larger issues with still-unaddressed memory leaks. 
This whole situation is rather baffling...

I would like to petition the developers to reconsider this decision based on a
poll taken through an appropriate newsgroup, regarding real-world usage of the
vertical tabs in Mozilla 1.1 and 1.2b.  Given the sweeping change the removal of
vertical tabs has required in the toolkit and toolbar.xml, I don't believe this
is too great a request.  Vertical tabs are functional and do serve a purpose.  I
don't believe they should be discarded in such a cavalier fashion.

Please reconsider this decision.
Hey, quite some people don't have 17" screens.
I use the 'grippie' function to free more space for the browser window.
With right-click some functions can be done also which are ob toll bars.

So please leave the function.

Bernard
Please stop spamming this bug and go and vote-for/work-on bug #45532 instead -
It will allow you to do everything the grippies did without causing confusion
for new users.
Sorry to be so late to the comment period, but this is a seriously bad idea. 
I've returned to Moz 1.1 simply to get grippies back.  Switching between English
and Japanese websites, it is often necessary to switch between 1280 x 1048
(English) and 640 x 480 (Japanese) for viewing grapic information such as
floorplans and charts.  I use the one-click switch option in Matrox QuickDesk to
do so.  However, once in the larger page mode, thre are two toolbars that are
not immediately necessary taking up 1.5-2cm of the top of the screen.

I have no objections to having the grippies off as a default if there is an "on"
option for people who need them in a drop down menu, as M$ has done.  

Don't render a good product useless.

CL
With reference to <a href="#c89">comment #89</a>:

Damien, my intent is not to "spam," but to comment directly to the "bug" in
question.  And in response to your exhortation that I instead vote for <a
href="show_bug.cgi?id=45532" title="ASSIGNED - Context menu for toolbars">bug
#45532</a>, I respectfully refuse.  Why?  Because the proposal for toolbar
context menus is not the same function provided by vertical tabs.  The mouse
motions required for using right-click context menus are, once again, not
equivalent to the one left-click motion used by vertical tabs.

In addition, with any piece of software there is a learning curve and a period
of break-in.  To remove a functional aspect of Mozilla on the grounds that it
was "too confusing," even when this function had been successfully utilized in
the Netscape Communicator package for years, is a weak justification at best,
and a poor excuse at worst.

Once again, I fail to see how a "bug" that garnered only 4 (now 5) votes
received so much attention.  If time had been taken to collect actual user data
on the use of vertical tabs, I firmly believe the Mozilla developers would have
received a different picture.  I personally am dismayed at the degree of
insufficient feedback on which this decision was based.

I implore the development group to seriously reconsider this decision.
>I implore the development group to seriously reconsider this decision.
This decision was already reconsidered. The toolbar grippies will be added back.
I found it ironic that twice in the last few days I've seen CNN showing some web
page, and both times they were using Netscape 6.x with the toolbars collapsed.

Yes, the grippies are confusing, and can really screw users over. On the other
hand, I bet we have another set of users and use them for presentations and
aren't even aware of view->show/hide.
Jan Varga: do you mean the widget, or their usage in Mozilla ? Where
is the bug for this ? Alternatively please point me to a discussion
of the rationale.

The existence of Phoenix^WWhatever makes any usability arguments for 
Mozilla itself pretty much beside the point (i.e. it is hopeless), but still ...
you've already seen the discussion and rationale that brought them back - it's
in comment 64.

i adapted bug 175091 into a bug for putting the grippies back in, if the
netscape folks feel the need to have a bugzilla bug before changing mozilla
code, that could be used for the purpose...
Well, if the grippies must come back can we have a "Lock Toolbars" in View -
Show/Hide as well please (and not at some indefinite point in the future). 

This doesn't need to make the grippies dissappear, necessarily, just that it
stops them doing anything. Should be trivial, right?
I don't want to start a discussion about it again, but me (and some other
people) are really missing the grippies. They were nice to look at, and it is
also a little bit complicated to go to the "View / Show/Hide" menu all the time
you want to hide a toolbar.

My proposal: until we have a nice solution, what about removing the grippies in
the default theme, but allow other themes to add them again?
Oops... there is a separate bug about restoring the grippies: Bug 178185 .
This was backed out by bug 175091. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Instead of removing the grippies totally once again, it would be useful if there
where a possibility to hide them. I suggest a menu entry under View -> Show/Hide.
Keywords: helpwanted, nsbeta1
Whiteboard: [need info] BEFORE COMMENTING, READ COMMENT 69! → Please don't comment with arguments, just vote. See comment 8 to turn them off.
Target Milestone: mozilla1.1beta → ---
I am in the camp of those who desparately miss grippies. I have three different
computers and have to use small screen resolutions on all of them, making it
very important to be able to temporarily maximize the content area of the
browser. It takes a lot of mousework to hide the toolbars through the menus due
to the fact that the you have to go into submenus. And how many people are clear
on which thing is the "component toolbar", which is the "personal toolbar", and
which is the "navigation toolbar"? This makes the menu method confusing, as
well. How many people who have spoken out against grippies are using in 800x600
mode? Not many, i suppose.

Those who have opposed the return of grippies on this bug have not addressed an
important issue raised here--why the grippies were removed from the toolkit
rather than from the themes. This is important because comments have indicated
that people have built applications and themes which depend on grippies. 

Now we have talk again of taking out the grippies to fix the performance
regression. If this is going to be done, can't we remove the grippies from the
themes instead of the toolkit? This seems like a correct way to satisfy
everyone. Those who like grippies can choose a grippy theme, those who don't can
choose a different theme, and third party developers don't have to redesign
their product due to a toolkit regression.

If grippies are retained the toolkit (as i hope they are), then perhaps those
that want them in the themes should file bugs, one on Classic and another on
Modern, to move the grippies to the right-hand side, where they're much less
likely to be clicked on accidentally. This might increase their chances of
retaining grippies in the two default themes.
Please excuse my clutziness!!! I meant for the previous comment to go into bug
175091, not here. Sorry sorry sorry. (I know that the two bugs are intertwined,
but i was referring to discussion on the other bug, and i haven't read the
discussion on this bug to know whether all of the same issues were brought up here.)
This is stupid - why was this reverted without any investigation into
alternatives? Even M$ gets this right in their browser where toolbars are locked
by default. Why is Mozilla going backwards in usability?
> why was this reverted

Because the decision to remove the grippies *entirely* was a tremendous mistake
in the first place with so many people using and liking them. Heavily used
features can be disabled by default, but you mustn't remove them like this.

> Why is Mozilla going backwards in usability?

Mozilla isn't going backwards in usability, just because "some" believe it is.
Usability is very subjective in nature.


I do really think that we should keep the grippies in the toolbox, so that they
can be enabled/disabled via themes. This moving in/out of grippy code doesn't
help anyone.
> Because the decision to remove the grippies *entirely* was a
> tremendous mistake in the first place with so many people using
> and liking them.

That's a matter of opinion.  Backing out a bug, once it's been decided upon and
implemented, should not be done unless there is a valid technical reason for it
(such as peformance regression).  As I understand it, the re-addition of the
grippies actually introduces performance degradation - does it not?  Backing it
out should only have been performed after careful consideration and workarounds.

What was the *procedural* reasoning behind the decision here?  It just seems to
me as if this is in violation of regular Bugzilla practices.  If not, somebody
please explain to me why it was acceptable.  (I'm not arguing for or against the
grippies, I just want to understand how this resolution was worked out.  Just a
change of opinion on Jan's part?)

Also, if grippies *ARE* back (as decided by the module owner ?) - should not
*THIS* bug be now marked as WONTFIX?  Surely, we can't always have one bug or
the other open at any given time, if they are in opposition to each other.

Or is Jan planning some kind of compromise?
Flags: blocking1.3b?
Does the workaround in comment 8 still apply? I suspended downloading new builds
when the bug 175091 fix went in.
> Does the workaround in comment 8 still apply? 

Yes. [Mozilla 1.3b; Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b)
Gecko/20030123]


If there're no *severe* performance or functionality penalties, the grippy
*code* should stay. Loved by many, hated by many - let's discuss the default
setting and keep the possibility to change it for those who want to. Anyone
should be able to live with some lines in his userChrome.css.
Personally, I think it should be reversed (if the code is to remain).  No
grippies by default (new users to Mozilla will never miss their absence) and
people can add CSS to put turn them on.
Flags: blocking1.3b?
> No grippies by default (new users to Mozilla 
> will never miss their absence) and
> people can add CSS to put turn them on.

But I think they should be turned on by default so new user can know that they
exist. Bug 175091 shows that many people love they, so it is also a inducement
for using Mozilla. If someone think the grippies are bad they can turn it off,
but this should not be done by css but by a preference in the UI. New user don't
want to make additions to files to change a pref. And I don't undestand why some
people think that many prefs in the UI-Dialog should be deleted, one point that
I (and I think very much other) like in mozilla are the count of preferences. 
With build 2003012508 (win95) I cannot hide the grippes with the workaround
given in comment 8 :-( Can anyone else confirm this?
Workaround still functioning with Mozilla 1.3b [Mozilla/5.0 (Windows; U; Windows
NT 5.0; en-US; rv:1.3b) Gecko/20030125]
The workaround, thankfully, still works for me too.
*** Bug 209154 has been marked as a duplicate of this bug. ***
Make it a Preferences option, enabled by default (in the Appearance section)?
Product: Core → Mozilla Application Suite
*** Bug 229480 has been marked as a duplicate of this bug. ***
*** Bug 292436 has been marked as a duplicate of this bug. ***
We went into extra effort to get grippies back into toolkit-based SeaMonkey, this bug is WONTFIX for SeaMonkey (suite), while it's FIXED for any other toolkit-based app.
Status: REOPENED → RESOLVED
Closed: 22 years ago17 years ago
Resolution: --- → WONTFIX
I read almost the whole list of comments and the huge majority of comments (basically except those of developers) are asking for the grippies to be removed, so we can safely assume that, based on the number of comments, most Seamonkey users dislike those grippies.
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: