Tk Source Code

View Ticket
Login
Ticket UUID: 2182522
Title: Ttk combobox fails to restore grab.
Type: Bug Version: 8.6.18, 9.0.5, 9.1.0
Submitter: sbron Created on: 2008-10-20 14:50:51
Subsystem: 88. Themed Tk Assigned To: jenglish
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2026-10-09 17:03:20
Resolution: Fixed Closed By: nemethi
    Closed on: 2026-10-09 17:03:20
Description:
With the code below, the combobox bindings fail to restore the grab after the user opens up the combobox list and then discards it again by clicking somewhere outside the list. The grab is restored correctly if one of the list items is selected.

The Quit button on top2 should never be active, but the button will work when clicked after opening and closing the combobox list without making a selection.

wm withdraw .
frame .tree1

toplevel .tree1.top
ttk::combobox .tree1.top.box -state readonly \
  -values {"Option 1" "Option 2" "Option 3"}
button .tree1.top.quit -text Quit -command exit

grid .tree1.top.box -padx 8 -pady 8 -sticky nwe
grid .tree1.top.quit -padx 8 -pady 8

toplevel .top2
button .top2.quit -text Quit -command exit
grid .top2.quit -padx 8 -pady 8

grab .tree1

 
Issue found on SuSE linux 11.0 with tcl/tk 8.5.4
User Comments: nemethi (claiming to be Csaba Nemethi) added on 2026-10-09 17:03:20:

Serhiy, many thanks for fixing this very long-standing bug! Merged into main, core-9-0-branch, and core-8-6-branch by commits [80bb8038], [efac46c2], and [3b02fe5f].


serhiy.storchaka added on 2026-10-08 18:44:22:

Still reproducible with 8.6.18 and 9.1 if the mouse button is still down when the grab is restored, e.g. when the list is closed by clicking another window of the application. ttk::RestoreGrab runs grab .tree1 again. A plain grab made while a button is down is temporarily promoted to a global grab until the button is released, and this fails because .tree1 is not viewable (it is a frame in the withdrawn .): grab returns the error "grab failed: window not viewable" and sets no grab at all. ttk::RestoreGrab ignores the error.

Proposed fix in branch x11-grab-unviewable-button: if a plain grab which was temporarily promoted to a global grab because a button is down fails because the window is not viewable, Tk_Grab makes the plain grab without the promotion instead of failing. An explicit grab -global of a window which is not viewable still fails. There is no automated test, since event generate does not change the state of the buttons which Tk_Grab gets from the X server; the attached script can be used to check it manually.


sbron added on 2008-10-21 01:25:44:
For this simplified script setting the grab to .tree1.top would avoid the problem. But of course the situation in the real application is a bit more complicated and this solution cannot be used as it would prevent necessary user interaction with other parts of the GUI.

jenglish added on 2008-10-21 00:41:32:
More info: [grab -global $w] is not allowed on unviewable windows, but plain [grab $w] is.  This is why the initial call to [grab .tree1] succeeds.

Sequence of events in the test script is: <ButtonPress-1> outside the application gets delivered to the ComboboxPopdown window, since it has a global grab.   Binding script for this event [wm withdraw]s the popdown shell.  When this receives an <Unmap> event, it calls ttk::releaseGrab -> ttk::RestoreGrab -> [grab .tree1].  

However, at this point Button-1 is still pressed, so Tk turns the ordinary [grab .tree1] into a "temporary global" grab (grep for "GRAB_TEMP_GLOBAL" in generic/tkGrab.c).

Recommended solution: do not [grab] unviewable windows, even with a plain (non-global) [grab].   In particular: changing [grab .tree1] to [grab .tree1.top] in the above script fixes the problem.

jenglish added on 2008-10-21 00:00:48:
Analysis: the combobox is actually attempting to restore the grab (path: ttk::combobox::UnmapPopdown -> ttk::releaseGrab -> ttk::RestoreGrab), but this fails ("grab failed: window not viewable") because . is not mapped.

Why [grab .tree1] succeeds initially and fails the second time is a mystery.  Further investigation required.

Attachments: