[Tcl-bugs] [ tktoolkit-Bugs-3044863 ] Tk Mac crashes when accelerator key spawns window

[SourceForge.net <no...@so...>]

Bugs item #3044863, was opened at 2010-08-14 10:57
Message generated for change (Comment added) made by lloydwood
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3044863&group_id=12997

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 01. Bindings
Group: None
Status: Open
>Resolution: Later
Priority: 5
Private: No
Submitted By: Lloyd Wood (lloydwood)
Assigned to: Kevin Walzer (wordtech)
Summary: Tk Mac crashes when accelerator key spawns window

Initial Comment:
I have a cross-platform application that I have just added menu accelerators (keypress shortcuts) to.Works fine on Tcl/Tk in Linux and in Windows (Cygwin Insight). Freezes on Mac OS X 10.6 Snow Leopard when an accelerator key is pressed to spawn a window.

I have a demonstration of this freeze (can't upload the tarball code, there's a 256k limit):
http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/savi-dev-kevin.tar.gz
tar xvf savi-dev-kevin.tar
cd savi-dev-kevin
make ARCH=macosx
./savi &
Click on the letterbox-shaped table-of-numbers window, then press either command-G to spawn the Global coverage window, command-F to spawn the fisheye window, or command-M to get the _empty space_ dialog - all windows will draw but missing a Mac titlebar and controls, and then the application freezes.

If you relaunch savi and only point and click on the menu options, everything is fine. If you relaunch savi and force use of popup menus rather than the Mac menubar with the savi -redrawn-menus flag (more on the reason for that flag below), accelerators work fine. It's accelerators plus the Mac menubar that is the problem.

A previous example you may have read about on the tcl-mac mailing list: The Tk Mac menubar never worked at all in 10.5 when Tk applications were launched from the terminal (I implemented a workaround for that in savi with -redrawn-menus and popup menus within window frames that avoided using the broken menubar - oddly, I see accelerators work fine from the Mac popup menus I implemented to work around that previous problem. Again, it's related to the Mac menubar). The release of 10.6 and the upgrade to Tcl/Tk in Xcode eventually fixed that problem (along with other Mac-specific problems like too-wide listboxes causing hangs), but that took eighteen months to happen, and has now exposed this crash.

This appears at first glance to be a similar _maybe the Tk shipped with 10.7 will fix it_-level Mac menuing bug; I do not see what I can do about it, as the installed base on Snow Leopard has Xcode with Tcl/Tk 8.5.7 and that's it.

Tk on the Mac should imo be as robust as Tk on other platforms, and should not require workarounds to prevent crashes.

(I posted about this to the tcl-mac list, but, despite being a subscriber, my posts hit a filter rule and are queued for a moderator to look at. Hence the background detail here.)

----------------------------------------------------------------------

>Comment By: Lloyd Wood (lloydwood)
Date: 2011-06-03 07:16

Message:
Reducing the priority may be reasonable (though I wonder about developers
implementing accelerators and not testing with shipping Tk in Leopard/Snow
Leopard - the safest workaround is not to implement accelerators at all) -
but putting 'works for me' when you've actually duplicated the crash
yourself with an unmodified test script is not, imo - testing that script
shows it doesn't work for you! 'Later' is probably better?


----------------------------------------------------------------------

Comment By: Kevin Walzer (wordtech)
Date: 2011-06-02 22:54

Message:
I've tested steffanhaller's sample script with various tweaks. While the
script as presented does cause Wish to freeze, the following adjustments
cause the dialog to display without any freeze:

1. Remove the tkwait line.
2. Map the accelerator to any key other than F1.

I'm not sure why F1 causes the crash and nothing else does--digging into
the Tk Mac source code does not yield any obvious problems--but in any
event a workaround is trivial. Given the ease of working around this issue,
it's hard to justify a priority of 9 for this bug, something that would
hold up a release. As a result I'm lowering the priority to 5 and resolving
it as "works for me" though I am leaving the bug open. If anyone else wants
to investigate this more closely and contribute a patch, I will be glad to
review it. 



----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2011-06-02 17:09

Message:
status for 8.5.10 ?

----------------------------------------------------------------------

Comment By: Kevin Walzer (wordtech)
Date: 2011-01-06 02:00

Message:
I've tried this sample script, and I find that commenting out the tkwait
line appears to fix the issue WRT F1. 

I also cannot reproduce the issue with another binding, cf. Command-S. If
you replace <F1> with <Command-S> it also works fine, with or without the
tkwait line. 

----------------------------------------------------------------------

Comment By: Lloyd Wood (lloydwood)
Date: 2010-09-19 18:32

Message:
Aha, my mistake, sorry.

I have Fink installed, so /sw/bin/wish also exists, and gets priority in
the path when I type:
wish accel.tcl
That doesn't crash - but is producing a Tk-on-X window with classic
popup-type menus in the window. It's a red herring.

/usr/bin/wish accel.tcl
produces a blank square non-functional window.

chmod +x accel.tcl
./accel.tcl
produces:
menu: command not found
and a host of other errors.

If I alter the first line of accel.tcl from #!/usr/bin/wish to say
!#/sw/bin/wish then
./accel.tcl
works non-crashingly as before.

I have duplicated your crash by doing:
/usr/bin/wish
and then using File/Source... to load in accel.tcl. Pressing F1 gets me a
freeze with a borderless 'Message text' window. So, yes, I've now
duplicated your crash, which has effectively duplicated mine in a lot less
code.

As well as being buggy, the Tk/wish supplied with OS X is poor at being
launched from the Terminal command line, as the above examples suggest.
SaVi launches from the command line, and couldn't even get a menubar in
10.5.

(I've found that I need to bind both upper and lower case keys, ie
Command-J and Command-j, to get binding to work. M1-Key to arbitraility
choose a modifier is new syntax to me; I've been setting $KEY by platform
to Ctrl or Command...)

----------------------------------------------------------------------

Comment By: Stefan Haller (stefanhaller)
Date: 2010-09-19 17:33

Message:
That's very strange; the script freezes reliably for me (I'm also on
10.6.4). How exactly do you launch it?

About menu bar vs. window: in my experience all you need is a main menu
with an accelerator, and any key binding with the same key; it doesn't seem
to matter what ui element the key is bound to.

As for F1 vs. other keys: I simply picked F1 randomly because it's the
same in the --accelerator option and the bind command.  Any other key also
reproduces the problem. For Cmd-J, for example, use "-accelerator Cmd-J"
and "bind . <M1-Key-j> show_dialog".

----------------------------------------------------------------------

Comment By: Lloyd Wood (lloydwood)
Date: 2010-09-14 11:36

Message:
Stefan,

I tried out your wish script on OS X 10.6.4 with the default Tcl/Tk
install supplied by Apple.

Though I reported this bug and can get SaVi to crash as I described in the
bug description, your script works fine to spawn the OK dialog - both when
doing fn-F1 or selecting standard function key use in the keyboard prefs
panel.

Comparing with my experience with SaVi (accelerator keys in menubar cause
a crash, accelerator keys from popup menus in window do not) your script
puts the menu in a window rather than the menubar - so I would not expect
it to crash.

Why did you choose F1? Do you have something else also using F1? Does the
script crash when a different letter-key accelerator is chosen?

----------------------------------------------------------------------

Comment By: Stefan Haller (stefanhaller)
Date: 2010-09-14 05:27

Message:
Here's a small example that illustrates the problem. Choosing "Show Dialog"
from the File menu works fine; hitting F1 hangs. (When using wish8.4
instead of wish, it works fine.)

This bug also affects git gui and gitk. For example, hitting Command-P in
git gui (for "Push") hangs.

----------------------------------------------------------------------------------

#!/usr/bin/wish

menu .mbar
. config -menu .mbar

.mbar add cascade -label "File" -menu [menu .mbar.file]

set m .mbar.file
.mbar.file add command -label "Show Dialog" -command show_dialog \
  -accelerator F1

bind . <F1> show_dialog

proc show_dialog {} {
    set w .error
    toplevel $w
    message $w.m -text "Message text" -justify center -aspect 400
    pack $w.m -side top -fill x -padx 20 -pady 20
    button $w.ok -default active -text "OK"  -command "destroy $w"
    pack $w.ok -side bottom -fill x
    tkwait window $w
}


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3044863&group_id=12997