Tk Source Code

ttk::menubutton does not release the grab until the menu has been hovered over with the mouse.

Recipe:

wm geometry . 200x200
ttk::menubutton .mb -text "Some menu";
menu .mb.m;
.mb.m add command -label "Item 1";
.mb.m add command -label "Item 2";
.mb configure -menu .mb.m;


Steps:
1. Click on the button; the menu appears.
2. Try to dismiss the menu by clicking on the blank area (the toplevel) to the
   rigth of the button *without hovering over the menu*.  We expect the menu to dissapear, but nothing happens.
3. Hover over the menu.
4. Click outside, as before.  The menu is dismissed.

Fix merged to trunk and core-8-6-branch, with new test case menu-38.1

Yes, it is working, thanks!

And, quite importantly: the glitch you describe is not due to the patch for the present bug, it was already present before it.

Well, outside of Tk behaviours of applications is not consistent in the case you describe.

For instance on Linux Debian 8 running KDE, in Konqueror if we press the button and release outside, without ever having hovered the menu, it does not get dismissed. On other applications, for instance Firefox, on the same Linux Deian 8 with KDE, the same action dismisses the menu.

I don't plan to make further "fix" on this topic.

Hello,

finally had some time to test the patch.  It works!

There is a small glitch, though.  When pressing the button, then (button still pressed) hovering over the menu, then hovering outside the menu and only then releasing, the menu is dimissed.  But if we press the button and release outside, without ever having hovered the menu, it does not get dimmissed.  This is, admittedly, quite an obscure corner case.

Thank you.

Best regards,
Adrián Medraño Calvo.

Non-regression test case menu-38.1 added in branch [bug-fa32290898]

Commit [79c4b253] was correct in fixing [3279221] but definitely created the present bug.

With the test case:

package require Tk
destroy .mb
wm geometry . 200x200
ttk::menubutton .mb -text "Some menu";
menu .mb.m;
.mb.m add command -label "Item 1";
.mb.m add command -label "Item 2";
.mb configure -menu .mb.m;
pack .mb

trying to close the posted menu (which is a tk_popup in fact) by clicking outside the menu does not work if the user did not (enter and) leave the menu beforehand.

When leaving the menu, variable Priv(window) that was set by [79c4b253] is reset to {}, which allows the menu to be unposted just a moment later when the <ButtonRelease> event triggers.

This does not happen when clicking outside the menu without entering/leaving it.

The fix is, in the binding to <ButtonPress>, to check whether the active item is "none", which indicates that the mouse was clicked outside of the menu dialog box, or not. If it is "none" then Priv(window) is reset to {}, which is understood by the binding to <ButtonRelease> to mean that the menu shall be unposted.

See proposed fix in branch bug-fa32290898

Fossil bisecting between 8.6.1 and 8.6.6 points at the following commit:

BAD 2014-02-06 21:24:55 79c4b25313e22487

[79c4b253] Merged. Ticket [3279221]: Fixed setup of popup menu to prevent immediate disappearance due to an event race. (user: andreask, tags: trunk)

At this time the original issue had been reported and then patched by Koen Danckaert (Koen, any input perhaps? Thanks!)

I added a: pack .mb to the code above.

Tested: Linux: 8.6.1  ok
Mac OS X: 8.6.3, 8.6.6 ok

Fails on Linux 8.6.6

We have encountered this problem as well and is very annoying.
The problem exists on Linux and Mac but not on Windows 10. 
The difference between Linux (Mac) and Windows is that the menu will appear under the mouse on Windows and therefore the menu gets automatically the focus because it already "hovers" over the menu. I expected that placing the menu under the mouse cursor will fix it.

If things are to complicated to fix, try ttk::combobox:
ttk::combobox is similar to ttk::menubutton and ttk::combobox does not have this problem. Only with ttk::combobox it is not possible to have a different labels in the drop down menu than in the label which appears in the button itself.