User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Selected view > toolbars > customize > add new toolbar > Gave it a name > OK > done. Toolbar name does not appear! Downloaded Mozilla today to my work computer but familiar with it for many months as I use it on my home computer. Created three different toolbar names, none appeared. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Select view > toolbars and name of toolbar should appear. Mozilla experienced error during download, I was supposed to send an email, like a fool I didn't.

if the toolbar doesn't have anything in it when you push 'done', it goes away. did you drag anything into the toolbar before pushing 'done'?

Firefox issue.

rescued from the mailbox that catches our bounces: Date: Mon, 25 Oct 2004 16:06:22 -0700 From: David Hitchcock <hitch@pacbell.net> To: bugzilla-daemon@mozilla.org Subject: RE: [Bug 265798] cannot create new toolbar! To awesomecheese Thanks for responding. I have Mozilla at home and at work. I can't make the "new toolbar" work on either. When I open view > toolbars > customize I see an item that says "add new toolbar". When I click on that, a dialog box open with a space to type in a name. I type in a name and click "OK", the dialog box disappears. I then click "done". I go back to view > toolbars ... and ... nothing. I am supposed to see the name of the toolbar I just created. I have created six or more toolbars with different names. When I type in the same name a second time I do not get a message that the name is already taken. Neither is there a blank toolbar at the top of the screen awaiting my tool inputs. Thanks for any suggestions you may have Hitch

I just noticed this on a Firefox trunk build (WinXP, build ID 20051013), it is blocking me from fixing bug 220701. When I try to create a new toolbar, it creates a *tiny* one, 1px or so tall. If I can manage to drag something onto it before I click Done, it will expand to the right size and stay visible. Otherwise, it is deleted when I click Done. I hope to attach a patch for this in a while.

This fixes the problem for me. I took a cue from the #PersonalToolbar selector in browser.css. I have no way of knowing whether this bug occurs on OSX and Linux, if it does I would be happy to amend the patch to try and fix gnomestripe and pinstripe too.

It was pointed out to me that the toolbar-shrinking issue affects the default navigation toolbar too. So this gives toolbars a minimum size (even when empty) across the board.

It seems that this was done to remove the user custom toolbar if all the icons are removed. IF not something to delete the toolbar should have been added. I would suggest: When the user opts for a new toolbar, create it, get a name and display it as a band (somewhat high as the normal toolbars [give them a minimum height, please]). If the user quits from here without adding toolbar items alert her that the toolbar doesn't contain anything, and therefore 'Should it be deleted or not?'. If the user opts to keep this toolbar for something else, then keep it. On a second visit, if the toolbar is still blank repeat the process above. OR add a 'Remove Toolbar' button, activate it only when additional toolbars are installed.

Hari, I think your suggestion would go better in bug 212990 or bug 266735. Unless I completely misunderstand the problem "hitch" is having.

Comment on attachment 199773 [details] [diff] [review] More generic patch At the very least, you need to fix the Pinstipe theme too. Also, this is the sort of beahvior change a peer should review.

This bug can also be reproduced on Firefox1.5/SunOS

Unbitrotted patch that fixes this problem on Windows. Lacking access to a Mac or Linux box, I tested this the best way I could: hacking the toolkit/themes Makefile to build pinstripe and gnomestripe instead of winstripe. Neither of those platforms appears to exhibit the bug; it seems limited to Windows. This is also supported by the fact that the pinstripe and gnomestripe toolbar.css files give toolbars a min-height, while winstripe does not.

I'm requesting blocking-firefox2 because this is a pretty egregious regression that makes adding a new toolbar next to impossible.

So, there seems to be a more serious bug now, it just plain doesn't work. ccing Mark, since this seems to be related to the events stuff.

mconnor, the new Mac-only very-broken behavior is another instance of RETURN keypresses being double-processed. The first RETURN says "OK" to the "New Toolbar" sheet, and the second one closes the "Customize Toolbar" window. I've got a patch for this in bug 337199. In fact, when I first took a look at this report, I didn't see anything wrong at all, since I'm running a test build with that patch in place. I'm not keeping all the goodness to myself, you can download the test build from bug 337199 and give it a try. (I don't see the tiny toolbar problem that the patches in this bug want to solve, even on win32.)

I can't reproduce either on win32.

Comment on attachment 216119 [details] [diff] [review] Another patch Ok, since no one is stepping up to say "I still see this" I'm going to clear this for now.

Definitely still seeing this on both Linux and Mac, but I don't think it should block.

This rather confused bug should now be OS/2-only, since pmstripe is the only thing that lacks a min-height for toolbars (unless ispiked remembers how he was managing to see it on Linux and Mac, at a time when both did have min-height). Since I don't have OS/2 to test, Peter, could you see if it's a problem, and if so whether the patch I'll attach fixes it? STR is: 1. Right-click Firefox toolbar, choose Customize 2. Click "Add New Toolbar" button 3. See whether you've added a toolbar that's 0px high, though maybe with visible borders, between the navigation toolbar and the bookmarks toolbar.

If pmstripe has a problem, this ought to be its fix.

Phil, yes, the newly created toolbar is indeed hard to see (only 2px high) until one drops an object in there. Is there a reason why you chose 19px specifically?

19px is the min-height in winstripe, which it picked up for unrelated reasons (my guess would be for the menubar's height, but I dunno) from bug 313388 - I needed a positive integer, and had no basis for choosing one, so I let someone else decide.

Comment on attachment 248203 [details] [diff] [review] Potential pmstripe fix [Checked into trunk and 1.8 branch] OK, I'm convinced. :-) This should go on both trunk and branch (where NPOTB applies). Will do that tomorrow unless someone beats me...

Comment on attachment 248203 [details] [diff] [review] Potential pmstripe fix [Checked into trunk and 1.8 branch] OK, checked this patch into trunk and branch. Thanks, Phil! Not sure if this should now be marked fixed (and fixed1.8.1.1). Because I cannot speak for the other platforms I leave it open for a few days.

Well, then I'll speak for them ;)

OK. In the meantime I realized that the fix will only be in 1.8.1.2 because the check-in happened too late for 1.8.1.1.

what a mess. This certainly isn't fixed in regards to the original report.. add a toolbar with nothing in it....it appears...but if you click done for the customize dialog without adding anything to the new toolbar, that new toolbar disappears. This bug as originally reported is a dupe of bug 268043. It looks like the bug morphed at comment #4. is that issue a duplicate of bug 325968? anyway verifying per the duped bugs