Created attachment 269631 [details] testcase Firefox's toolbar customization window is a fake sheet, so it suffers from other problems instead, but Thunderbird still uses the same window.openDialog(... "dependent") on all platforms, and for Mac, the dependent window doesn't stay on top like it's supposed to, so when you click on something in the toolbar of the main window, to drag it to the palette, the whole main window comes to the front, hiding where you were going to drag it. STR: 1. Open trunk Thunderbird, right-click the toolbar, select "Customize..." or 1. Save this bug's testcase as a local file (so it can get permission to use openDialog), open it in trunk Firefox, click the Test button, click Allow for the request for UniveralBrowserWrite. 2. Click in the main (browser or Thunderbird) window. Expected: The customize (or blank, for the testcase) dialog stays on top of the main window. Actual: The main window comes to the front, hiding the dialog if it's in position to cover it.
Hmm, I don't think my testcase is testing the same regression: although it stays on top on Windows and Linux, and not on Mac, it also doesn't stay on top in Firefox long before Cocoa widgets were turned on, while Thunderbird's troubles only start with Cocoa widgets.
And since Thunderbird switched to a <panel> in bug 394873, seeing it there will require getting rid of one or more of the TOOLBAR_CUSTOMIZATION_SHEET defines in various and sundry makefiles.
Related to or same as bug 404283?
It would seem not to be.
Summary: openDialog(... "dependent") doesn't stay on top, breaking Thunderbird's customize toolbar → openDialog(... "dependent") doesn't stay on top, breaking Sunbird's customize toolbar
Summary: openDialog(... "dependent") doesn't stay on top, breaking Sunbird's customize toolbar → openDialog(... "dependent") doesn't stay on top
You need to log in before you can comment on or make changes to this bug.