-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
IDLE: Freeze when closing Settings (& About) dialog on MacOS #78301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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. |
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. Bug A:
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. 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. |
I’m sorry for not being clear. This problem appears with Tk 8.6, even in Le lun. 30 juil. 2018 à 02:51, Terry J. Reedy <report@bugs.python.org> a
|
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. |
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. 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'. |
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 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 Conclusion: With the exception of Save and cancelled Goto, closing modal dialogs seems bugged in various ways. |
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. |
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. Reproducing the 'wrong' text window being activated will require something new with two Toplevel text windows. |
Removing the call "self.grab_set" in configdialog.py (line 87 or so) and help_about.py (line 47 or so) appears to fix the problem with the main window freezing when the modal dialog is destroyed on macOS. "Grab" has never worked properly on Tk on the Mac, but it has additional problems in the Cocoa implementation of Tk; it causes all kinds of problems with the event loop and is best avoided altogether. If the call to grab is crucial on other platforms, it can be wrapped in a call to "tk windowingsystem ne aqua" to exclude the Mac. If other modal dialogs present similar behavior on the Mac, look for calls to grab and try omitting that call. I'll leave it to someone else to propose a thorough patch, but this should point you in the right direction. |
The tkinter doc could use a section on 'OS-tk peculiarities and interactions' ;-). Anyway, thanks again. Some of the 'Windows peculiarities' I noted above, where the test behaved better on Mac, may be due to the absence of calls that should be avoided on Mac. Perhaps I can factor out some of the dialog setup and shutdown code, get it right for each platform, and then use it for all or at least multiple dialogs. |
I can confirm that removing .grab_set() calls fixes this issue on macOS 10.13.5 with Python 3.7.0 from python.org. Searching for those calls in all of IDLE's code lead me to discover additional similar issues, e.g. with the search dialog and the text viewer. Removing the .grab_set() and .grab_release() calls fixes those issues as well. I tried IDLE with these changes on Windows 10 with python build from the latest master branch. Things appear to be working well without these calls. Is it reasonable to simply remove the grab calls entirely? I've created a PR with such a change to facilitate evaluating this approach. |
Confirmed on macOS 10.13.5 with the new Python 2.7.15 64-bit from python.org which bundles Tcl/Tk 8.6.8. The same fix works: Removing the grab_set() calls fixes the freezing after closing the about and config dialogs. |
I can confirm that removing the grab_set() calls fixes the locking. But am I the only one to notice that the dialogs aren't modal any more? |
Adding self.grab_release() in the ok() method for the dialogs BEFORE destroy() solved the problem for me, keeping the grab_set() methods in place (uncommented, actives). |
I've checked again the source code in config_key.py, configdialog.py, help_about.py, query.py, searchbase.py, textview.py and added a self.grab_release() in functions like ok() and cancel() before the call to self.destroy() and I see no more lock/focus issues. Maybe the grab was kept in the non-existent (destroyed) dialog window, so the click events could not be transferred to the pyshell or editor, but, because of a local (not global) grab, clicking on another application's window, by losing focus and grab, completely freed the event-chain, then clicks in IDLE were correctly received. |
Adding grab_release() calls also resolves the issue. Tested on mac and win. PR updated with this approach, IMO ready for review. |
I wrote the following justification for adding grab_release while Tal was revising his PR to make the change. I will look at the PR now and test on Windows. Vlad, I was wondering about modality. Properly de-modalizing a dialog requires more than just removing grab_set. The parent of a modal dialog is a window with a menu, an instance of idlelib. If a dialog were not modal, its parent could be deleted, which would also delete the dialog and any un-saved and un-acted-upon data. This is true of Debugger, whose parent is Shell. Duplicate dialogs would also be possible, as is true of IDLE Help, whose parent is root, unless explicitly prevented, as is true of Debugger (Shell knows if there is a Debugger instance). Removing modality has been discussed in various places, such as in bpo-24760, which focuses on Settings. If it were de-modalized, its parent should be root and only one copy allowed. Mark Roseman noted on the issue that "because modal doesn't fully work on the Mac, you can actually create multiple copies of the config dialog!". So my preferred short-term fix, once confirmed, for 3.7.1, would be the addition of grab_release. Merely removing grab would have to be Mac-specific, and I would expect new problems and complaints. Properly de-modalizing on all platforms, where sensible, is a longer-term project. Notepad++ on Windows, for instance, has a non-modal singleton Find dialog (with Replace and Find in Files on separate tabs), designed as such, that operates on the 'current' editor tab, unless one selects 'Find All in All Open Documents' to work on all of them. PS: Tal Einat also get 'autorelease pool' errors when trying to run IDLE on locally built 3.7.0. |
Why remove the 2.7 version? This bug occurs with 2.7.15 on macOS. |
Removing 2.7 was unintended, from simultaneous editing. This is one of the exceptional cases where a backport is worth the risk (which seems here extremely low). I will remove it from the PR because auto backport will fail because of file renames, in addition to internal changes. Here are the new name to old name translations, where not a just a case change, needed to prepare a 2.7 patch. config_key keybindingDialog |
Many thanks for the report and follow through, Vlad! Thank you too, Kevin, for your help in resolving this. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: