385714 - openDialog(... "dependent") doesn't stay on top

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect)

Description

[Phil Ringnalda (:philor)]

Attachment: 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.

Comment 1

[Phil Ringnalda (:philor)]

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.

Comment 2

[Phil Ringnalda (:philor)]

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.

Comment 3

[Håkan Waara]

Related to or same as bug 404283?

Comment 4

[Phil Ringnalda (:philor)]

It would seem not to be.

Comment 5

[Stephen A Pohl [:spohl] (OOO until 2/27)]

Just tried to reproduce this and believe that this has since been fixed or mitigated. Please reopen if this isn't the case.