Christiaan Hofman Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

When you hit the Add New Toolbat button in the toolbar customization sheet, a sheet is added *behind* the toolbar customization sheet. This sheet is therefore inaccessible. There never should be more than one sheet on a single window (and this is the reason why). 

Reproducible: Always

Steps to Reproduce:
1. Choose View > Toolbars > Customize...
2. Hit the Add New Toolbar button
Actual Results:  
A second sheet is added behind the customization sheet. It is not accessible.

Expected Results:  
The extra sheet sheet should be added as a sheet on the customization sheet. 

Another problem is that the sheet extends from another part of the window. The customization sheet extends from below the bookmarks toolbar, while the extra toolbar name sheet extends from directly below the title bar. That is inconsistent. Sheets on a given window should always extend from the same place. The standard behavior in MacOSX is from directly below the title bar, so the toolbar customization sheet is wrong.

	Christiaan Hofman Reporter
	Comment 2 • 17 years ago

I don't think it's the same bug. Bug 395334 talks about moving a sheet above windows from another app. Here the whole problem is that 2 sheets are added to the same window which leads to a conflict (one sheet covering another one). They should be added hierarchically, i.e. the second one should be added as a sheet to the first one. This is how sheets on a Mac should behave. I do think that is a completely different problem.

	Phil Ringnalda (:philor)
	Comment 3 • 17 years ago

That might be the case if it was two sheets, but it's not: it's a sheet and an XUL <panel noautohide="true">.

	Christiaan Hofman Reporter
	Comment 4 • 17 years ago

Than *that's* actually the bug: they both *should* be sheets, not panels. Why? Because they modify the window layout. Certainly if you want to be more Mac native you should also folow the Mac HIG, and it clearly says that these should be sheets. So I still think it's a different bug from Bug 395334 (though also different from what I thought it was).  

	Phil Ringnalda (:philor)
	Comment 5 • 17 years ago

The customization window should be a sheet, the Mac native window type which opens from the bottom of the titlebar? Don't you see a tiny little problem with customizing the toolbar, when it's covered by a sheet?

Native customization is done by just calling runToolbarCustomizationPalette which opens a unique window type controlled by the system, one which looks a bit like a sheet but isn't. Firefox is a cross-platform app that doesn't have native NSToolbars with native NSToolbarItems, so it can't customize them that way, so it imitates the native customization with an XUL element which happens to be named panel, which currently suffers from bug 395334 when it has the attribute noautohide, which causes it to stay above everything, including other apps and including sheets it opens in its parent window, which causes the problem you observed, a problem which the author of the patch in bug 395334 says (in bug 403942 comment 3) it solves.