Modal windows not implemented for Gtk+. Parity issue with windows/mac.

Fixes checked in. Should behave same as windows platform.

syd, could you provide a testcase, or mark this verified if you know it works? thanks

Test case for Linux: Bring up preferences. Try clicking in other places of Apprunner, e.g., menu bar, buttons, etc., outside of prefs dialog. If nothing responds, the prefs dialog is modal.

cool. once my menus come back, i'll verify this bug.

ok, so modal windows work in all ways but one (please correct me if i'm wrong): in nova, when you check you bring up preferences, the parent window is ALWAYS behind the prefs. try as you might, you'll never bring the parent to the foreground. in seamonkey, this is not the case. the parent is 100% defunct while prefs are open (which is good), but you can bring the parent to the foreground. i think that is bad from a user experience standpoint. should this be reopened, or is that the correct behavior?

syd, i'm tempted to reopen this bug. try opening the preferences. then close the parent window. poof, it disappears, while the prefs stay open and responsive. i know that can't be right. is that a separate bug?

Well, this doesn't sound to me like we are violating the modality of the prefs window. What is the expected behaviour in this case?

you shouldn't be able to close the parent of a modal window. try it in communicator on any platform. open the prefs dialog and do whatever you can to get the parent window in front of the prefs dialog. it can't be done. then try to close the parent windows without closing the prefs dialog. also impossible. this might not be your problem, but it is a bug. should i file it as a new one?

Reopen this bug open. I was tracking the functionality of Windows (e.g. 95, NT) modality which appears now to be application modal (at one point, you could go and select menu items and such from the top level window). This has changed, and it looks like we need to sync up the Linux story.

reopening bug. New Problem: On RedHat Linux 5.2 kernel 2.2.9, modal windows are _almost_ modal. The parent window must not be allowed to stay in the foreground. [not a problem on mac/win32] On MacOS 8.51, modal windows are truly modal. The only problem is mouseover events are still sent to (and received by) toolbars and buttons. They are not clickable, but appear to be. [not a problem in linux/win32] Builds Tested: 1999-07-14-16 RedHat Linux 5.2 kernel 2.2.9 1999-07-14-17 WinNT 4.0 sp4 1999-07-14-16 MacOS 8.51

Moving to M9.

The problem isn't that the dialog isn't modal, it is. Modality does not extend to the window decorations. So, the user can kill the toplevel window as you described. The real problem is we are not handling the relationship between the modal dialog and its parent. Pavlov is dealing with a bug that we are not setting the transient-for hint for the popups (modal or not modal) correctly. Try this on 4.x on solaris, for example. You can bring up preferences and then (I'm using CDE as my example) go to the menu hung on the window decorations and close the main browser window. The prefs window will go down too, this is what we want, but it has *zero* to do with modality. Pav, perhaps you could right a quick test app with a transient-for popup dialog and see if closing the toplevel (transient-for) parent causes the popup to go down too (and the application to exit). If so, then this bug is a duplicate of the bug you are working on, with an added test case. If not, open a new bug.

so pavlov, is this a dup of your bug? i agree that you can close communicator 4.x windows while the prefs are open, _but_ the prefs window closes itself as communicator exits. the last remaining issues: 1.closing the navigator window should close the open prefs window 2.the prefs window should never be allowed to hide behind it's parent window.

issue #2 is fixed, when i get around to it i'll open a bug about #1. marking verified on 1999-08-13-08 RedHat Linux 6.0 (GNOME/enlightenment) 1999-08-13-08 WinNT 4.0 sp5 1999-08-13-08 MacOS 8.51