#3016 Aqua menus do not get re-enabled

obsolete: 8.6b3

Try the following using Tk 8.6b3 (Tk-Cocoa) on OS X (happens in OS X 10.7 and 10.8 at least). This works with any of the wish menus apart from the "Wish" menu itself:

1. Launch wish
2. Select one of the wish menus and see that the items are enabled
3. type into the console: "tk_chooseColor"
3. while the dialog is open: select one of the wish menus and see that the items are disabled
4. dismiss the color dialog
5. select one of the wish menus and see that the items are still disabled

At step 5, the menus should be enabled again, but they are not. If you do the same sequence but skip step 3, then everything is OK. So it seems that choosing a menu while a modal dialog is open will correctly show disabled menu items but the menu will never be re-enabled afterwards.

This happens not only in plain wish but also with custom menus from [. configure -menu]


  • Kevin Walzer

    Kevin Walzer - 2012-09-27
    • assigned_to: das --> wordtech
  • Kevin Walzer

    Kevin Walzer - 2012-09-28

    I can only reproduce this issue when I'm running these steps in the console that is shipped with Tk (and which is usually suppressed in a running app). If, instead, I run these commands interactively from Terminal on a fresh build of Tcl/Tk trunk, the menus are enabled and disabled as expected. Similarly, running this short script:

    pack [button .b -command tk_chooseColor -text "Choose Color"]

    things work as expected.

    So, I'm curious about the use case that led to the discovery of this bug. Is it evident in your application? Because based on what I've seen on my own system, I can't imagine a scenario where a bug like this would ever be displayed in my own apps.

  • Torsten Berg

    Torsten Berg - 2012-09-28

    I can reproduce that the problem not occurs from the Terminal.

    But the use case is just accidental user interaction that can lead to locking the app. Take, e.g., your FileMorph program (downloaded a trial). Launch the application, click on e.g. "Select directory" and a modal dialog pops up. Now image a user not knowing that this dialog is modal (ok, it is quite obvious in this case, but I have applications where it is not) and who wants to access the menu bar in oder to quit the program. It is greyed out so the user cannot do anything here. Then the user dismissed the open dialog and of course expects to be able to access the menus now. But he can't. So now, he cannot quit FileMorph anymore using the menu or even choose any other action - just by accidentally hitting the menu with the mouse during an open modal dialog.

    I find this is worth hunting down ...

  • Kevin Walzer

    Kevin Walzer - 2012-10-02

    Committed fix in trunk and 8.5 to leave menus enabled during modal dialogs.

  • Kevin Walzer

    Kevin Walzer - 2012-10-02
    • status: open --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks