See bug 71614 for history. I know MPT has a load of good arguments for why we should remove these tooltips from the browser, but I won't include them all here. :) Assigned to stephend who volunteered to fix this.

If that is all there is to remove. r=hwaara

are you done? (r=hwaara) ;)

Quite finished, yes. Pending sr= from Ben or Alec Flett, I can check this in.

sr=alecf

Fixed!

stephend: <menubar id="main-menubar" persist="collapsed"> should be <menubar id="main-menubar" persist="collapsed"/>

Oh, and severity is now critical because this causes the browser not to start on linux (it complains of unmatched XUL tags).

I think you messed up on your checkin. here comes the correction...

just landed my patch.

Sorry about this, I couldn't build today because of the Win2K startup crasher bug in my tree, but that's not an excuse..I'm lame. Thanks for wiping my ass on this.

Seth checked in the fix for this last night.

mass accepting my bugs.

I messed up, changing from assigned fixed to resolved fixed..sorry for the spam.

Um, what? I just collapsed all my toolbars, and I want to open my personal toolbar. How do I do that on one click? With tooltips, I could, now I can't. Did we take this out just so we could?

This is a major usability regression for me. Unless you give me some other very clear mechanism to determine which collapsed toolbar is which then this basically destroys the collapsing feature for me. I don't care about tooltips for expanded toolbars but it's pretty damn hard to figure out which one is which when the order (horizonatally, when collapsed) is different depending on the order they were collapsed. Until there is a toolkit change that gives toolbars a consistent collapsed order then this change should be backed out. I'd rather have some information there than no information.

Re-opening. If I can get module owners and the UE team to agree, I can easily implement these again. People complained the last time I implemented them, but this point is extremely valid, and I think it offsets any "annoyance" people had in the past with tooltips showing for the collapse/expand widgets.

Is there a way to have tooltips only when the toolbars are collapsed? Or else maybe it's good to have tooltips always so new users can know which toolbar is which. (i.e. so they can hide it using the View > Show/Hide menu or whatever) Don't know if that's a strong enough reason...but it may be enough of a reason to not try to hide them when not collapsed.

Moz0.9.1 is long gone. Dont want this to fall off radar if it's critical. Target Milestone should be set for sometime in the future. (I could do it, but I understand that that isn't something normal people should touch) :-) If we're waiting on whether tooltips are good or bad, I'd say lets put them in and debate about them then. Better to err on the side of usuability than people whining about bloat. (3 lines of bloat is not bloat) :-)

Seems like we need a good discussion, and a conclusion. Can we take this to n.p.m.ui? Please read bug 71614 and bug 71615, in which I argued for tooltips, but lost.

Some of my comments: 1. Okay, I probably shouldn't have capitalized "Toolbar". Will update that when/if this patch needs checking in. 2. When/if this patch goes in, I don't want anymore bugs on removing the functionality. I'll accept bugs on wording though. 3. In the past, a number of people wanted me to remove the tooltips (see bug 71614 and 71615). 4. I'll need some wording help, especially with the funky "Headers toolbar" in mail/news composition's window, and possibly address book. 5. This patch does *NOT* cover Composer, but does cover the following: * Navigator * Mail Window pane * Mail Composer window * Addressbook I had done Navigator, Address Book, and Mail/News before, but didn't want to mess with Composer. I'd need someone to help, or complete the patch. Someone will have to update NIM's commercial grippies, if this patch goes in. The patch currently uses messenger.dtd where it was already referenced, so as not to duplicate things like &menuBar.tooltip and &mailToolbar.tooltip. Other things that are specific, like &formatToolbar.tooltip, live in their respective files, such as messengercompose.dtd. In other words, no additional dependencies were created on Navigator, and Address Book is always installed with Mail/News so we're safe there.

Updating keywords, milestone, and priority.

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 ... -- bdonohoe@netscape.com, bug 47873.2000-08-07 I'm fine with tooltips being added to the toolbar grippies as a temporary measure until the collapsibility problem gets sorted out -- as long as you add them *only* on the toolbar and menu bar grippies, not on other grippies, and as long as the word `Widget' doesn't appear in the final patch.

terri, patty, not sure which of you should get this one...

I filed bug 100701, which Hyatt says wouldn't be that difficult to implement. Please don't spam that bug unless you have useful comments regarding that specific implementation, or patches ;-).

Sorry to CC so many people at once. I need mass-reviews on this bug, if it to be implemented anytime soon. I need wording and UI reviews/approval from: mpt, german, jglick, robinf code reviews from cmankse for editor code reviews from varada/ducarroz for mail/news/addressbook code reviews from ben for navigator I'll send mail, too. Thanks!

I agree with mpt's comments on 9-19. Keep the text short and simple, the name of the toolbar. Don't add tooltips for grippies, the change in the cursor on hover is the visual indicator for these items. Mail: Mail Toolbar Menu Toolbar AB: Address Book Toolbar Menu Toolbar Compose: Mail Toolbar Menu Toolbar Formatting Toolbar Address Bar

jglick's suggestions OK with me.

Comment on attachment 50368 [details] [diff] [review] Patch, last one had bogus find/replace changes. According to JGlick, you should use "Menu Toolbar", not "Menu bar". With that change, r=cmanske for Composer files.

Comment on attachment 50826 [details] [diff] [review] Patch, addresses comments from jglick sr=sspitzer

Anybody volunteer to finish up the JS console, History and the Manage Bookmarks window? I'd like all of the grippies to be consistent, before landing.

I'm sorry, Charlie's comment made me think twice. "Menu Bar" not "Menu Toolbar" is the correct term. "Menu bar - a special area displayed across the top of a window directly below the title bar" (windows guidlines). (While a "Toolbar" is "a panel that contains a set of controls designed to provide quick access to specific commands or options.) If its not too late...

Actually, just like with "toolbar", most HIGs refer to it as one word - "menubar". Can you please use that form instead?

The current format in all the "View: Show/Hide-->" menus is two words, "Status Bar", etc. So probably want to be consistent with that convention for tooltips also ("Menu Bar"). If we want to change this format globally, i would suggest a new bug to change all instance at one time.

Hakan, I am not sure what HIGs you are referring to, both the Apple UI Guidelines (p52) and the Windows UI guidelines (p122) use the 'official' term "menu bar". As for Navigator, the terms should be: Menu Bar Navigation Toolbar Personal Toolbar

Joe Hewitt, can you review the console.dtd and .xul files? Paul Chen, can you review the navigator/history.dtd and .xul files? Ben Goodger, can you review the navigator/bookmark.dtd and .xul files? Robert Ginda, can you review the chatzilla.dtd and .xul files? This just implements tooltips on the grippies (as a temporary measure, until we figure out a better solution). The wording on the Menu Bar has been reviewed already by German, but I'll need each area to review their code. Thanks

I don't see any diffs for chatzilla.dtd OR .xul in that patch.

Fixed. all mail and editor diffs had r=sspitzer and r=cmanske. Wording had r= german/jglick/robinf.