After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 455627 - Keyboard input gets confused with modal windows
Keyboard input gets confused with modal windows
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.10.x
Other Windows
: Normal normal
: ---
Assigned To: Cody Russell
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-07-10 17:45 UTC by Cody Russell
Modified: 2008-02-05 17:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (9.48 KB, patch)
2008-02-05 03:14 UTC, Cody Russell
needs-work Details | Review
Updated patch (11.29 KB, patch)
2008-02-05 16:35 UTC, Cody Russell
committed Details | Review

Description Cody Russell 2007-07-10 17:45:07 UTC
Tor pointed out in bug #112404 that when you click the titlebar of a transient/modal owner window the keyboard focus will stay on the child window.  This does not happen for non-modal transient windows.
Comment 1 Cody Russell 2007-12-26 02:37:48 UTC
I'm thinking about this some more, and I guess the real bug is that the modal parent shouldn't allow you to activate its titlebar.  Because the focus -should- be on the child window, that's the entire point behind modal windows.

I need to try to find an example of modal windows to see how they do it normally in the Win32 world, just for reference.
Comment 2 Cody Russell 2008-02-05 03:14:26 UTC
Created attachment 104456 [details] [review]
Proposed patch

This patch does a few things.  It implements a modal window stack using GSList, and uses that from WM_MOUSEACTIVATE to determine if it should eat the activation and mouse click when window != current modal.

It also handles the problem of alt-tabbing to a modally-blocked window.  I tried using WM_SYSCOMMAND and listening for SC_NEXTWINDOW/SC_PREVWINDOW/SC_TASKLIST, but couldn't get that to work in a useful way.  So instead I'm now watching WM_ACTIVATE to see when the window is activated by some means other than a mouse click (since we handle that with WM_MOUSEACTIVATE), and if the window is modally blocked then I activate the current modal window.  This should also take care of other ways of activating the window, like if the app tries to call ActivateWindow() on a modally-blocked window.

This seems to cover every angle I can think of.  If anyone has any additional thoughts, let me know!

Also, this patch fixes bug #511111 as well.
Comment 3 Tor Lillqvist 2008-02-05 07:21:50 UTC
Some stylistic comments about the patch: the non-static functions you added should be prefixed with an underscore. And as they aren't intended to be called by libgtk like the ones suffixed with _libgtk_only, they shouldn't be declared in gdkwin32.h, but gdkprivate-win32.h.

(Yeah, I notice there are a couple of old libgdk-local functions that aren't prefixed with underscore. That should be changed for consistency. Feel free...)

As to the functionality of the patch, I trust you have investigate this well enough. Please fix the style issues and commit to trunk first and then after some week to the stable branch as well.
Comment 4 Cody Russell 2008-02-05 16:35:13 UTC
Created attachment 104490 [details] [review]
Updated patch

Updated patch with fixes for style.
Comment 5 Cody Russell 2008-02-05 17:12:09 UTC
2008-02-05  Cody Russell  <bratsche@gnome.org>

        * gdk/win32/gdkprivate-win32.h
        * gdk/win32/gdkevents-win32.c
        * gdk/win32/gdkwindow-win32.c
        * gdk/win32/gdkwindow-win32.h
        * gdk/win32/gdkwin32.h:
        Modal window rework.  (#455627 and #511111)