Tk Source Code

On Windows, when there is a grab, the user can interate with other toplevels on the same app using the taskbar.

To replicate this, on wish, execute this code:

toplevel .t ; grab .t

You can activate the main toplevel (the one titled "wish84") clicking its icon on the windows taskbar. It comes to the front, possibly hiding the toplevel that has the grab. This is annoying and confusing. I know a case where the user rebooted Windows, after apparently being stuck with an unresponsive application. It goes against the semantics of grab, too. No Tk event is fired, so the programmer can do nothing to prevent this.

In tkWinWm.c, the case where the user clicks onto a non-grabbed toplevel is managed (see WmProc, handling of WM_MOUSEACTIVATE message). Putting similar code on the handling of the WM_ACTIVATE message resolves the problem by making sure that no matter what toplevel the user tries to activate with the taskbar, if there is a grab active, the toplevel that has the grab stays active and on top.

There is other related problem with the current implementation of grab: the user can interact with the system menu of the non-grabbed toplevels, thus being able to close, minimize, etc them. An ideal solution would be to disable the system menu for all toplevels except the grabbed one, and enable it again when the grab is released. However, an improvement over the current situation is to ignore WM_SYSCOMMAND when there is a grab (except for the grabbed toplevel).

Finally, IMO the user should be not allowed to minimize a grabbed window.

Patch implementing all this attached.

To recapitulate, it is my undersanding that, when there is a grab, the user shouldn't be allowed to interact with those parts of the application's GUI that are outside the limits of the grabbed portion. Although the patch does not resolve enterely the problem, it avoids GUI states that can cause trouble and confussion both to the user and developer.

Backported the fix to 8.5 branch (post 8.5.6)

Fixed on 8.6 HEAD.

File Added - 308103: grab_fix.patch

This patch extends the patch provided with bug 1 to address some 
issues handling toplevels in Tk when a grab is set under Windows.
At the moment if a grab is set then the non-grabbed toplevels reject
activation attempts from the user via mouseclick. However if you click
the toplevel's entry in the taskbar you can bypass this. The original
patch addresses this but we also run into a race when the user clicks
on the toplevel title and starts a move. The posted activate event
causes an early termination of the move which aborts the grab temporarily.
We fix this by delaying the handling of the activate event while a move
is in progress.

The patch also adds some handling of WM_SYSCOMMAND. As originally provided
this prevents minimizing an grabbed toplevel. The original also rejects any
system commands when a grab is present for the non-grabbed windows but I have
permitted move and resize which seems to correspond to some applications
in testing when a dialog is shown.

Possibly we will stick with the original scheme of preventing any interaction
with non-grabbed toplevels when a grab is present.

File Added - 257795: patch