cannot create new toolbar!




14 years ago
12 years ago


(Reporter: hitch, Unassigned)


(Blocks: 1 bug, {verified1.8.1.2})


Firefox Tracking Flags

(Not tracked)



(1 attachment, 3 obsolete attachments)



14 years ago
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:

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.

Comment 1

14 years ago
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.
Assignee: general → bugs
Component: Browser-General → Toolbars
Product: Browser → Firefox
QA Contact: general → bugzilla
rescued from the mailbox that catches our bounces:

Date: Mon, 25 Oct 2004 16:06:22 -0700                                          
From: David Hitchcock <>                                      
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     
Thanks for any suggestions you may have                                        
Assignee: bugs → nobody
QA Contact: bugzilla → toolbars
Version: Trunk → unspecified

Comment 4

13 years ago
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.
Assignee: nobody → jhenry
Blocks: 220701
Ever confirmed: true


13 years ago

Comment 5

13 years ago
Created attachment 199496 [details] [diff] [review]
Proposed patch

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.
Attachment #199496 - Flags: review?(bugs.mano)

Comment 6

13 years ago
Created attachment 199773 [details] [diff] [review]
More generic patch

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.
Attachment #199496 - Attachment is obsolete: true
Attachment #199773 - Flags: review?(bugs.mano)

Comment 7

13 years ago
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. 


add a 'Remove Toolbar' button, activate it only when additional toolbars are

Comment 8

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


13 years ago
Attachment #199496 - Flags: review?(bugs.mano)
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.
Attachment #199773 - Flags: review?(bugs.mano) → review-

Comment 10

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

Comment 11

13 years ago
Created attachment 216119 [details] [diff] [review]
Another patch

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.
Attachment #199773 - Attachment is obsolete: true
Attachment #216119 - Flags: review?(mconnor)

Comment 12

13 years ago
I'm requesting blocking-firefox2 because this is a pretty egregious regression that makes adding a new toolbar next to impossible.
Flags: blocking-firefox2?
Keywords: regression
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.
Flags: blocking-firefox2? → blocking-firefox2+

Comment 14

13 years ago
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.
Target Milestone: --- → Firefox 2 beta1
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.
Attachment #216119 - Flags: review?(mconnor)
Flags: blocking-firefox2+

Comment 17

13 years ago
Definitely still seeing this on both Linux and Mac, but I don't think it should block.
OS: Windows 2000 → All
Hardware: PC → All
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.
Assignee: jhenry → nobody
Component: Toolbars → Toolbars and Toolbar Customization
Flags: review-
Product: Firefox → Toolkit
QA Contact: toolbars → toolbars
Target Milestone: Firefox 2 beta1 → ---
Version: unspecified → Trunk
Created attachment 248203 [details] [diff] [review]
Potential pmstripe fix [Checked into trunk and 1.8 branch]

If pmstripe has a problem, this ought to be its fix.
Attachment #216119 - Attachment is obsolete: true

Comment 20

12 years ago
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 22

12 years ago
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...
Attachment #248203 - Flags: first-review+

Comment 23

12 years ago
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.
Attachment #248203 - Attachment description: Potential pmstripe fix → Potential pmstripe fix [Checked into trunk and 1.8 branch]
Well, then I'll speak for them ;)
Last Resolved: 12 years ago
Keywords: fixed1.8.1.1
OS: All → OS/2
Hardware: All → PC
Resolution: --- → FIXED

Comment 25

12 years ago
OK. In the meantime I realized that the fix will only be in because the check-in happened too late for
Keywords: fixed1.8.1.1 → fixed1.8.1.2
what a mess. This certainly isn't fixed in regards to the original report.. add a toolbar with nothing in 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
Keywords: fixed1.8.1.2, regression → verified1.8.1.2
You need to log in before you can comment on or make changes to this bug.