Repository navigation
IDLE code completion window can hang or misbehave with mouse or <return> #59990
Description
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 2017-06-14.16:36:38.718>
created_at = <Date 2012-08-27.00:35:00.748>
labels = ['expert-IDLE', 'type-bug', '3.7']
title = 'IDLE code completion window can hang or misbehave with mouse'
updated_at = <Date 2017-06-14.20:10:53.229>
user = 'https://bugs.python.org/suddhasourav'bugs.python.org fields:
activity = <Date 2017-06-14.20:10:53.229>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2017-06-14.16:36:38.718>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2012-08-27.00:35:00.748>
creator = 'suddha.sourav'
dependencies = []
files = []
hgrepos = []
issue_num = 15786
keywords = []
message_count = 51.0
messages = ['169175', '169178', '169191', '171842', '171849', '171880', '220751', '220785', '241368', '241429', '264921', '264926', '264928', '264929', '264962', '265265', '265446', '265450', '265456', '265466', '265488', '265490', '265491', '265495', '265498', '270903', '272070', '293305', '293309', '293339', '293345', '293355', '293373', '293376', '293389', '293392', '293474', '293598', '294461', '294736', '294745', '294766', '294805', '295979', '295980', '296011', '296013', '296015', '296029', '296030', '296031']
nosy_count = 11.0
nosy_names = ['terry.reedy', 'taleinat', 'ned.deily', 'roger.serwy', 'markroseman', 'Al.Sweigart', 'serhiy.storchaka', 'littleq0903', 'suddha.sourav', 'paulsfo', 'louielu']
pr_nums = ['1517', '1811', '2187', '2198', '2199']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15786'
versions = ['Python 3.6', 'Python 3.7']Metadata
Metadata
Assignees
Projects
- Status
Activity
suddhasourav commentedon Aug 27, 2012
In IDLE, pressing tab brings up the code completion menu - however, the scrollbar, when clicked, does not scroll - it disappears. Same goes for clicking an option in the code completion widget - it disappears. Keyboard navigation (pgup/pgdown/up/down) and tab works. In addition, pressing enter does not autocomplete but execute what was meant to be selected.
littleq0903 commentedon Aug 27, 2012
On which platform?
suddhasourav commentedon Aug 27, 2012
Platform is Windows 7 Professional 64-bit. Sorry for not including the information!
suddhasourav commentedon Oct 3, 2012
I would like to let you know that the issue also persists for Windows 8 Pro
RTM. Has anything been decided on this bug?
On Fri, Aug 31, 2012 at 5:56 PM, Terry J. Reedy <report@bugs.python.org>wrote:
serwy commentedon Oct 3, 2012
I can confirm that the existing behavior of IDLE prohibits clicking on the scroll bar on Windows (but not Linux). Clicking on an item in the window closes it without actually selecting the clicked item. This is true on both Windows and Linux.
On Windows, the <FocusOut> event is generated when selecting the completion window, causing it to close. On Linux with Gnome3.4, the scroll bar is clickable without closing the window.
By removing "<FocusOut>" from HIDE_SEQUENCES in AutoCompleteWindow.py, the completion window can now take focus. However, the completion window will need some work since key presses in the focused window doesn't change the text selection.
suddhasourav commentedon Oct 3, 2012
Thank you for the hint, Roger! On my side, I have changed the
HIDE_SEQUENCES tuple to ("<Key-Escape>",) and it is giving me the behaviour
I desired. However, I am not sure if this is a fix of the real issue.
I tried IDLE on OpenSUSE 12.2 last night and faced the problem in its other
manifestation, which you describe.
Thank you again tor the quick feedback!
[-]IDLE code completion window does not scoll/select with mouse[/-][+]IDLE code completion window does not scroll/select with mouse[/+]ned-deily commentedon Jun 16, 2014
Investigating a user report of IDLE freezing on OS X when mouse clicking on the code completion menu led me to this issue. The behavior I see varies depending on the Tk variant in use. The basic test case is:
With two different X11 Tk's (Debian Linux 8.5.x and OS X X11 8.6.x), clicking on the selection causes the code completion window to disappear but the code completion text does not appear in the edit window. Further, then pressing "Return", "a", and "Tab" to try a new code completion results in the code completion window momentarily appearing then disappearing. If one uses the mouse to click on and change focus to another IDLE window (e.g. the shell window), then click on and return focus to the edit window, the code completion window starts working again, at least, until using the mouse to click on a selection again.
With the current Cocoa Tk 8.5.x on OS X (the most commonly used Tk there), the behavior is even more confusing to the user. After mouse-clicking on a code completion menu item, the code completion menu disappears but then the edit window becomes unresponsive to either the keyboard or the mouse until focus is moved, again by clicking on another IDLE window and then returning to the "hung" edit window.
Oddly enough, the older Carbon Tk 8.4.x on OS X (used with 32-bit-only Pythons) seems to handle this all correctly.
I did not try this with a Windows Tk. I also did not systematically check all current versions of IDLE with all of those Tk variants but spot checking saw similar behavior on current dev (pre-3.5), 3.4.1, and 2.7.x.
[-]IDLE code completion window does not scroll/select with mouse[/-][+]IDLE code completion window can hang or misbehave with mouse[/+]terryjreedy commentedon Jun 17, 2014
Idle Help, Completion sections "Two tabs in a row will supply the current ACW selection, as will return or a double click." On 3.4 windows, tab-tab works, one click dismisses the box immediately but without disabling it. Contrary to the claim above, <return> dismisses the box with no entry and enters <return> into the window (shell or editor). <space> on the other hand, does the same as tab-tab + enters a space. I actually like this better than return, but the doc and behavior should match and the widget never become disabled. The doc does not say anything about navigation.
I recently committed an *incomplete* test_autocomplete from one of last summer's GSOC students, but it obviously does not test what really needs to be tested.
terryjreedy commentedon Apr 17, 2015
I closed bpo-23954 in favor of this one.
AlSweigart commentedon Apr 18, 2015
Additionally, pressing tab after the autocomplete window has appeared should not just update the text but also close the autocomplete window.
The repro steps are (on Windows 7 64-bit, Python 3.5):
paulsfo commentedon May 5, 2016
I'm new to IDLE. I just upgraded to Mac El Capitan from Snow Leopard, and installed Python 3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44).
I have had the IDLE window freeze so many times (when clicking on something in the autocomplete window as described by Ned Deily) that I consider IDLE unusable. I'm not familiar with Python bug practices but I would consider this a serious bug because, as a product manager would probably put it, this is going to drive away a significant percentage of new users (i.e., unexplained freezing of the product when doing something which seems natural -- clicking on the item that I want to select).
Unrelated question: which can't Mac Spotlight find tkinter.py? is it in some compressed file or something, so I can't find a standalone py file?
32 remaining items
terryjreedy commentedon May 30, 2017
Almost there. Clicking on a list item or the scrollbar works to select an item or scroll. Clicking outside the box *before* clicking elsewhere works to dismiss box. Clicking outside the box *after* clicking inside dismisses the box, but also results in the following, printed twice.
The immediate fix is to catch AttributeError or, perhaps better, wrap the body of _hide_event_check with "if self.autocompletewindow:". There should be no need to hide the window if it is already gone.
I am puzzled as to why clicking in the box affects later clicks outside the box.
mlouielu commentedon May 31, 2017
I fix this as:
I think this another different behavior on different platform. I can't reproduce this on Linux...
mlouielu commentedon Jun 14, 2017
Terry, would you like to verify the fixed? I think it will be good if this fix can be backported in 3.6 before 3.6.2 released.
terryjreedy commentedon Jun 14, 2017
Now that I know how to backport with confidence, and have cleared the backlog, and synched 3.6 with 3.7, I want to review this next. I would like to get it in 6.2, but 6.2 was due yesterday, but delayed, and there is no info on how long the delay is. This may be one of the harder patches to review and test, but I will try tomorrow. (Its midnight here now.)
My main concern is that we not break one thing while fixing another, which I have done before, due to inadequate tests. I will try to develop a test protocol from doc subsection 2.2 Completions to list what works without the patch.
terryjreedy commentedon Jun 14, 2017
New changeset 778b484 by terryjreedy (mlouielu) in branch 'master':
bpo-15786: IDLE: Fix mouse clicks on autocompletetion window (bpo-1811)
778b484
terryjreedy commentedon Jun 14, 2017
New changeset 3280579 by terryjreedy in branch '3.6':
bpo-15786: IDLE: Fix mouse clicks on autocompletetion window (bpo-1811) (bpo-2187)
3280579
terryjreedy commentedon Jun 14, 2017
After hand-testing everything I could think of, including clicking outside the box after clicking inside, I applied the click (and Mac crash) fix to 3.7 and 3.6. As far as I know, it should appear in 3.6.2rc whenever that appears. If so, I hope people who verified the bug will download and try to verify the fix.
I will open separate issues for the following and list them on the autocompletions master issue, bpo-27609.
Improve autocomplete tests.
Improve 'Completions' doc subsection.
Stop insertion of \n into text when closing box
(see opening message above).
I will also post a message on bpo-27609 about behavior issues mentioned here that are not part of any open issue.
terryjreedy commentedon Jun 14, 2017
New changeset 32fd874 by terryjreedy in branch 'master':
bpo-15786: Fix IDLE autocomplete return problem. (bpo-2198)
32fd874
terryjreedy commentedon Jun 14, 2017
New changeset 6628006 by terryjreedy in branch '3.6':
[3.6]bpo-15786: Fix IDLE autocomplete return problem. (bpo-2198) (bpo-2199)
6628006
terryjreedy commentedon Jun 14, 2017
With the severe click bug apparently fixed, I focused on Suddha Sourav last sentence "In addition, pressing enter does not autocomplete but execute what was meant to be selected." In current freshly started IDLE, for example
brings up a box with [compile] highlighted. On hitting <Return> one sees
>>> re.c ... NameError: name 're' is not defined 'c' has not been completed to 'compile' and \n has been inserted into the Text widget, causing the line (in the shell) to be compiled and executed. I imagine that everyone would prefer ">>> re.compile" with the cursor at the end. The fix is so simple that I decided to include it here, today. In autocomplete_w.AutoCompleteWindow.keypress_event, change elif keysym == "Return": self.hide_window() return None to elif keysym == "Return": self.complete() self.hide_window() return 'break'[-]IDLE code completion window can hang or misbehave with mouse[/-][+]IDLE code completion window can hang or misbehave with mouse or <return>[/+]