GNOME Bugzilla – Bug 157779
modal window doesn't stays on top of its parent window
Last modified: 2007-07-13 02:09:01 UTC
Please describe the problem: modal window doesn't stays on top of its parent window, you can click on a parent window and the first one which is modal goes below the parent. on linux modal window stays always on top of its parent window. Steps to reproduce: 1. gtk_window_set_transient_for 2. 3. Actual results: Expected results: Does this happen every time? Other information:
This problem doesn't seem to exist in GTK 2.6 for Win32. The modal will stay on top of its parent. However, modal dialogs do not block other windows or dialogs from recieving focus, and this does cause odd behavior if other dialogs or windows besides the parent of the modal dialog are open. Basically, it is possible to select another dialog or window and give it focus, thus causing it to be placed on top of the modal dialog. However, it is not possible to do anything with the window or dialog since the modal dialog blocks everything except changing focus. This is not the expected behavor. Basically, modal dialogs should block focus changes as well as other events.
The problem persist in version 2.6.8 and 2.6.10 for win32. The modal dialog/windows is placed behind its parent. But the focus is well set. In my particular case, the modal dialog is completely ocluded by the main window, and so the main is useless until i move the main and let the modal visible. The installers i used were the Gtk+/Win32 Development Environment (runtime, devel, docs, glade, etc.) Installer 2.6.10-rc1 (.exe, 9.39M) and the Gtk+/Win32 Development Environment (runtime, devel, docs, glade, etc.) Installer 2.6.8-rc1 (.exe, 9.01M) from the http://gladewin32.sourceforge.net/ page. The bug appears everytime, w/o exception. The bug appears in windows ME, XP and XP S2. In the linux version of my app, the modals works perfectly.
this problem persists in gtk+ 2.8.7 for win32(works correctly for linux). it's also still annoying as hell. :)
Can you please write a test program to exploit this problem? I have tried to reproduce this with my Win32 build and failed.
Fixed in bug #112404.
*** This bug has been marked as a duplicate of 112404 ***