435461 - Mac modal-dialogs are shown on top of every window open in the OS

Status: RESOLVED WONTFIX

(Core :: Widget: Cocoa, defect, P3)

Description

[Nick Kreeger]

Mac modal dialogs that aren't shown as sheets currently have top-level Z-ordering across the OS instead of just the application's windows.

For an example of this, force-quit Firefox (trunk or FF 3 RC1) and reopen Firefox. When the "Restore Previous Session" dialog reappears - try to move a another window from another application (i.e. a Camino window) on top of the dialog - the Firefox modal dialog remains on top.

For an example of what a modal dialog should look like, open up Safari and call up a simple JS prompt ("javascript: alert('test');").

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

What's odd is that kreeger's example dialogue ("Restore Session") is the same one that often/typically opens behind other applications and other apps' windows post-Crash Reporter.  (I thought I had that filed, but I guess not; I can only find the one about the Crash Reporter itself opening in the bg).

Comment 2

[Steven Michaud [:smichaud] (Retired)]

This is a byproduct of how the patch for bug 395465 emulates modal
windows (as opposed to sheets) -- the modal window is given a high
"window level" for as long as it's displayed (for as long as it's
modal).  For another example see attachment 278445 [details] (referred to in bug
395465 comment #0).

The only way to fix this is to explicitly change every modal window's
"level" when Firefox loses app-focus (and restore them when it regains
app-focus).  I suspect this will be tricky ... but we probably need to
do it.

Comment 3

[Nick Kreeger]

> The only way to fix this is to explicitly change every modal window's
> "level" when Firefox loses app-focus (and restore them when it regains
> app-focus).  I suspect this will be tricky ... but we probably need to
> do it.
> 

Unfortunately - it is not that easy. I have a patch that fixes this - in order to successfully lock down the window ordering, the subviews of the window need to implement a few methods.

Just changing the window |level| flag will not fix this in the case that the app loses focus (and is shifted to a |NSNormalWindowLevel|). It is possible to select any window to bring it up front.

Comment 4

[Nick Kreeger]

Attachment: WIP V1

Here is a WIP patch. From my research, the way to disable window reordering is to override two methods (|shouldDelayWindowOrderingForEvent:| and |acceptsFirstMouse:|) and make a call to |[NSApp preventWindowOrdering]| inside the |mouseDown:| call.

I found this here:
http://www.cocoadev.com/index.pl?PreventWindowOrdering

In order to accomplish this, we must traverse down the subviews to make sure they can disable click-through when needed. 

There are two open issues with this patch:
1.) Background windows are disabled unless you click on the titlebar. Clicking on the titlebar _will_ bring the application into focus.

2.) The Application window menu provided for the dock (context-click on the icon in the doc) needs to be disabled. Window re-ordering will happen if the user picks out a menu item from that popup.


I should also note that I'm not happy with my new method names, and those will probably change in the next version of the patch.

Comment 5

[Nick Kreeger]

Attachment: Disable Sheets Hack Patch

Here is a patch that helps with testing - it turns off sheets all the time.

Comment 6

[Nick Kreeger]

Attachment: HTML Testcase

This is a test HTML file that I use for showing JS modal prompts.

Comment 7

[Samuel Sidler (old account; do not CC)]

Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 11

[Stephen A Pohl [:spohl]]

Markus, do you know if there is any work left to do here?

Comment 12

[Markus Stange [:mstange]]

I'd say it's not worth doing more work here. Firefox front-end has been switching to custom implementations of window-modal dialogs, so the problematic APIs are mostly unused in Firefox.