#3016 Aqua menus do not get re-enabled

obsolete: 8.6b3
closed-fixed
Kevin Walzer
5
2012-10-02
2012-09-26
Torsten Berg
No

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]

Discussion

  • 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