IDLE: Freeze when closing Settings (& About) dialog on MacOS

[vtudorache]

BPO	34120
Nosy	@rhettinger, @terryjreedy, @ronaldoussoren, @taleinat, @ned-deily, @serhiy-storchaka, @miss-islington
PRs	bpo-34120: fix IDLE freezing after closing dialogs #8603 [3.7] bpo-34120: fix IDLE freezing after closing dialogs (GH-8603) #8613 [2.7] bpo-34120: fix IDLE freezing after closing dialogs (GH-8603) #8614 [3.6] bpo-34120: fix IDLE freezing after closing dialogs (GH-8603) #8615 bpo-34120: fix text viewer to call grab_release() only when needed #8616 [3.7] bpo-34120: fix text viewer to call grab_release() only when needed (GH-8616) #8617 [3.6] bpo-34120: fix text viewer to call grab_release() only when needed (GH-8616) #8618

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = <Date 2018-08-02.08:33:46.576>
created_at = <Date 2018-07-15.09:53:29.852>
labels = ['OS-mac', '3.8', 'expert-IDLE', 'type-bug', '3.7']
title = 'IDLE: Freeze when closing Settings (& About) dialog on MacOS'
updated_at = <Date 2018-08-02.08:33:46.574>
user = 'https://bugs.python.org/vtudorache'

bugs.python.org fields:

activity = <Date 2018-08-02.08:33:46.574>
actor = 'taleinat'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2018-08-02.08:33:46.576>
closer = 'taleinat'
components = ['IDLE', 'macOS']
creation = <Date 2018-07-15.09:53:29.852>
creator = 'vtudorache'
dependencies = []
files = []
hgrepos = []
issue_num = 34120
keywords = ['patch']
message_count = 27.0
messages = ['321686', '322646', '322654', '322698', '322717', '322718', '322764', '322825', '322837', '322845', '322850', '322851', '322874', '322875', '322880', '322884', '322889', '322891', '322893', '322917', '322919', '322922', '322923', '322924', '322926', '322928', '322929']
nosy_count = 11.0
nosy_names = ['rhettinger', 'terry.reedy', 'ronaldoussoren', 'taleinat', 'wordtech', 'ned.deily', 'serhiy.storchaka', 'miss-islington', 'walters', 'vtudorache', 'eamartin']
pr_nums = ['8603', '8613', '8614', '8615', '8616', '8617', '8618']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue34120'
versions = ['Python 2.7', 'Python 3.6', 'Python 3.7', 'Python 3.8']

[vtudorache]

When closing the IDLE's Preferences dialog the IDLE's Console window and/or Editor window (whichever was active before) doesn't show cursor/caret any more. One must click on Desktop or another window then click again in the IDLE's window in order to regain cursor/caret. This problem shows on macOS High Sierra, Python 3.6.N and 3.7.N (and even 3.5.N), with the provided installers (64 bit, 64/32 bit, Tk 8.6.8) and with self-compiled Python(s). After a number of openings IDLE will crash with an @autoreleasepool issue. I've compiled Tcl/Tk and Python with CC=clang CXX=clang++ MACOSX_DEPLOYMENT_TARGET=10.9 (10.10, 10.12 also), Tcl/Tk with and without --enable-threads, always with --enable-64bit --enable-framework and --enable-dtrace, clang 902.0.39.2 (Apple LLVM version 9.1.0), Python was compiled with and without --enable-dtrace and --enable-optimizations, with --enable-framework.

[terryjreedy]

On idledev thread "Mac IDLE 3.7.0 freezes when accessing Preferences", Walter Schnyder reported something similar. Combining two posts:

"using python.org Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24) [Clang 6.0 (clang-600.0.57)] on darwin [64-bit] and came across these [new] bugs on several Macs, all running OS X v 10.13.5.
[Has run IDLE before, back to 3.4.]

Bug A:

1. From the shell select Preferences in the IDLE menu.
2. Cancel the Preferences to get back to the Shell
3. The shell is frozen. It doesn’t even react to CONTROL-D.

The only way I found to resurrect it is to control-click the shell window and select “Go to file/line” causing an error message to appear. Click OK and the shell comes back to life.

Note: This doesn’t only happen when accessing preferences. It also happens when selecting “About IDLE” in the IDLE menu."

After starting with 'python3 -m idlelib'

"The same problems occur. There is no error in the terminal window.
But I learned something new: after running the steps for bug A, IDLE is frozen (no blinking cursor, not responding to Control+D. However, if I bring another application’s window to the front (by clicking on it) then click back on IDLE’s window, this resurrects IDLE, the cursor blinks and Control+D quits."

test_idle passes. When running 'python3 -m idlelib.configdialog' or 'idlelib.help_about', which run a human-viewed test, there is no problem when closing either dialog.

Vlad, if I understand your post, you *do* see the problem with 3.5? With the python.org installer and tk 8.5? As far as I know, no one has had a problem with this. Or only with a private compile with tk 8.6?

This is important because 3.5 IDLE has not been touched since about 18 months, and if there is only a problem when using tk 8.6, then I have to suspect that this and other new problems are result of tk 8.6 on Mac or tkinter needing a patch to support it.

[vtudorache]

I’m sorry for not being clear. This problem appears with Tk 8.6, even in
Python 3.5 (compiled by me).
I’ve succeeded to reproduce only once the @autorelease pool error (it
appeared after several open/close of the preferences or about window). Did
anyone else see it?

Le lun. 30 juil. 2018 à 02:51, Terry J. Reedy <report@bugs.python.org> a
écrit :

Terry J. Reedy <tjreedy@udel.edu> added the comment:

On idledev thread "Mac IDLE 3.7.0 freezes when accessing Preferences",
Walter Schnyder reported something similar. Combining two posts:

"using python.org Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24)
[Clang 6.0 (clang-600.0.57)] on darwin [64-bit] and came across these [new]
bugs on several Macs, all running OS X v 10.13.5.
[Has run IDLE before, back to 3.4.]

Bug A:

1. From the shell select Preferences in the IDLE menu.
2. Cancel the Preferences to get back to the Shell
3. The shell is frozen. It doesn’t even react to CONTROL-D.

The only way I found to resurrect it is to control-click the shell window
and select “Go to file/line” causing an error message to appear. Click OK
and the shell comes back to life.

Note: This doesn’t only happen when accessing preferences. It also happens
when selecting “About IDLE” in the IDLE menu."

After starting with 'python3 -m idlelib'

"The same problems occur. There is no error in the terminal window.
But I learned something new: after running the steps for bug A, IDLE is
frozen (no blinking cursor, not responding to Control+D. However, if I
bring another application’s window to the front (by clicking on it) then
click back on IDLE’s window, this resurrects IDLE, the cursor blinks and
Control+D quits."

test_idle passes. When running 'python3 -m idlelib.configdialog' or
'idlelib.help_about', which run a human-viewed test, there is no problem
when closing either dialog.

Vlad, if I understand your post, you *do* see the problem with 3.5? With
the python.org installer and tk 8.5? As far as I know, no one has had a
problem with this. Or only with a private compile with tk 8.6?

This is important because 3.5 IDLE has not been touched since about 18
months, and if there is only a problem when using tk 8.6, then I have to
suspect that this and other new problems are result of tk 8.6 on Mac or
tkinter needing a patch to support it.

----------
components: +macOS
nosy: +ned.deily, rhettinger, ronaldoussoren, taleinat, walters
stage: -> needs patch
title: IDLE Caret/Focus Lost -> IDLE: Freeze when closing Settings (&
About) dialog on MacOS
versions: +Python 3.8

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue34120\>

---

[terryjreedy]

Thanks. This is evidence for my suspicion that this results from a problem with the new tkinter/tcl/tk8.6 delivered with 3.7. See bpo-34275.

PS: when replying by email, please delete the quote, which is redundant with the post on the web page.

[terryjreedy]

I closed bpo-34281 as a duplicate of this. Eric Martin said "After entering a line number, clicking OK brings to the foreground and makes active the first hidden window (in the simplest case where we have just one window for a .py file and the Shell window, the former being in the foreground, clicking OK brings the Shell window to the foreground)."

Normally, one window is active, as indicated by the traffic lights, and one widget has the focus, which for entry widgets is indicated by the cursor. I tested with 3.7.0 with MacOS 10.13.6 and a shell and editor window.

IDLE > About IDLE: closing either way turns lights on in original window but text does not get focus (no cursor). Neither TAB nor click return focus, but the window is not frozen either. Selection, deselection, and copy work, cut and paste do not.

As far as I know, on Mac, cut and paste as well as copy and selection are handled entirely by tk, and not IDLE. My interpretation is that the window is 'stuck' in an 'illegal' state, partly enabled, partly disabled. Clicking and activating the other window disables the stuck window, so that clicking on it enables it.

IDLE > Settings works the same. But...

Options > Configure IDLE works as Eric described above. Closing with OK or Cancel or Red light activates the *other* window, in a stuck state.
(If there is no other IDLE window, then something else must be clicked to unstick the originally active window.)

Edit > Go to line: If one cancels, behavior is normal. If one enters a number and clicks OK, the other window is activated (lights on) without a cursor while the cursor goes where requested in the original, apparently 'inactive' window. And keyboard input goes where the cursor is, in that unlighted window. AFAIK, this is 'impossible'.

[terryjreedy]

After more experiments on Windows, the 'stuck' window -- active, no cursor, only copy works -- is a read-only window. I looked at other windows.

Modal
Edit > Find (Command F)
Edit > Replace (Command R)
When closed, neither window is activated. This seems wrong (on Windows, the original is), but I don't know what normal is on Linux or Mac.

Options > Settings > Keys Tab > Get New Keys for Selection: When this is closed, the text window rather than the settings dialog is activated in read-only state. Must click on Settings dialog. New selections does appear in keys list.

Options > Settings > Highlights > Choose Color for: When closed, all blue highlights on tab disappear. Colorchooser is supplied by tk and might be from Apple.

File > Save (Copy) As: This OS supplied dialog is an oddball. Only the red light turns gray and cursor remains without blinking. The dialog has no lights and closed it turns the red back on and the cursor blinks.

Non-modal
Help > IDLE Help
Debug > Debugger
Debug > Stack Viewer
Help > Turtle Demo
When closed, last active other window is activated.

Conclusion: With the exception of Save and cancelled Goto, closing modal dialogs seems bugged in various ways.

[wordtech]

I've observed this behavior myself, and wonder if you are hitting some edge case in Tk-Mac event processing (there used to be a lot of issues with this and we thought we had addressed them). I don't want to code-dive into Python's implementation of these dialogs, so can you provide a simple script that demonstrates the issue and I'll take a closer look? Often bugs of this sort can be addressed at the script level with some tweaks.

[terryjreedy]

As with the tooltip modules (see bpo-34275, msg322824), the dialog modules all have run-when-main test functions. Unittests are also run, before the human-verified test.

python3 -m idlelib.searchbases fails in that the driver-box is not activated (lighted) when the searchbase box is closed.
Replace 'searchbase' with 'search', 'replace', or 'grep' which text subclasses of Searchbase, and an intermediate lighted window with a Text widget and 2nd button appear. (For the grep test, click the window and maybe type something to put focus on the text.) Click the button to get the dialog. Close it. The text window does not get lighted. It does on Windows. (There are other glitches on Windows that do not appear in IDLE itself).

Reproducing the 'wrong' text window being activated will require something new with two Toplevel text windows.