Skip to content

Conversation

@taleinat
Copy link
Contributor

@taleinat taleinat commented May 27, 2021

Due to the <Configure> event sometimes being triggered after some delay, the completion list window may no longer exist when the handler is called. Therefore it is necessary to catch potential TclError exceptions in the handler's code.

This PR is a somewhat heavy-handed solution (simply wrapping most of the code in a try/except block), but seems like what's needed for such an event handler.

https://bugs.python.org/issue41611

…onfig_event()

Due to the <Configure> event sometimes being
triggered after some delay, the completion list
window may no longer exist when the handler is
called.  Therefore it is necessary to catch
potential TclError exceptions in the handler's
code.

Signed-off-by: Tal Einat <[email protected]>
@terryjreedy
Copy link
Member

terryjreedy commented May 27, 2021

PIPELINES, Win32, same failure twice.
======================================================================
FAIL: test_incremental_editing (idlelib.idle_test.test_colorizer.ColorDelegatorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\1\s\lib\idlelib\idle_test\tkinter_testing_utils.py", line 54, in new_test_method
    raise exception
  File "D:\a\1\s\lib\idlelib\idle_test\tkinter_testing_utils.py", line 38, in after_callback
    next(test_generator)
  File "D:\a\1\s\lib\idlelib\idle_test\test_colorizer.py", line 597, in test_incremental_editing
    eq(text.tag_nextrange('KEYWORD', '1.0'), ())
AssertionError: Tuples differ: ('1.0', '1.1') != ()

First tuple contains 2 additional elements.
First extra element 0:
'1.0'

- ('1.0', '1.1')
+ ()

Why only Pipelines and not others? Why only Win32 and not Win64? I am tempted to ignore, but I will trigger a rerun by editing the new comment. (If you think too much so, you can expand.)

Edit: rerun passed.

Condense comment.
Comment on lines 242 to 244
self.is_configuring = True
if not self.is_active():
return
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it is a bug to leave self.is_configuring True when returning. It seems that not self.active should be added to the condition above. I also remember doing some test that indicated that this function may still be executed past here more than once. But another issue.

Copy link
Contributor Author

@taleinat taleinat May 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, though unrelated to the bug in the bpo issue. Want us to fix this in this PR while we're here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tempted but no. Partly discipline -- we have coherent problem and solution we agree on, lets merge it (when you are ready). We have done really great today with good focus. Partly I want to retry the test I remember to check for any anomaly. Start with just a PR, if you want, after this is merged into you local clone. Or start with wider issue Clean up autocomplete_w code. There is a too-big function that I would like to split. And maybe other things. Oh, and maybe some tests needing review.

try:
# Position the completion list window
text = self.widget
text.see(self.startindex)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heavy-handed? We could move the 'try' down a few lines. I considered whether 'see' is useful even when code below fails, but cannot see that it is. So I am OK with enclosing the entire logical block.

If we caught TclError after 261, what would we do? To return, we would have to duplicate the cleanup code after the new pass. To 'break', we would have to wrap this block with a fake loop. Both are worse.

Copy link
Contributor Author

@taleinat taleinat May 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I did write "somewhat heavy-handed" ;)

But yes, I too believe this is actually a good solution, besides perhaps refactoring to introduce a more consistent mechanism to avoid uncaught exceptions in event handlers.

But that seems out of scope for this fix.

@miss-islington
Copy link
Contributor

Thanks @taleinat for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.9.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request May 28, 2021
…onfig_event() (pythonGH-26404)

Since the <Configure> event may occur after the
completion window is gone, catch potential
TclError exceptions when accessing acw.
(cherry picked from commit 4e2e5c1)

Co-authored-by: Tal Einat <[email protected]>
@bedevere-bot
Copy link

GH-26419 is a backport of this pull request to the 3.10 branch.

@bedevere-bot bedevere-bot removed the needs backport to 3.10 only security fixes label May 28, 2021
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request May 28, 2021
…onfig_event() (pythonGH-26404)

Since the <Configure> event may occur after the
completion window is gone, catch potential
TclError exceptions when accessing acw.
(cherry picked from commit 4e2e5c1)

Co-authored-by: Tal Einat <[email protected]>
@bedevere-bot
Copy link

GH-26420 is a backport of this pull request to the 3.9 branch.

@taleinat taleinat deleted the bpo-41611/IDLE-autocomplete-winconfig-catch-tcl-exceptions branch May 28, 2021 06:07
taleinat pushed a commit that referenced this pull request May 28, 2021
…onfig_event() (GH-26404)

Since the <Configure> event may occur after the
completion window is gone, catch potential
TclError exceptions when accessing acw.

(cherry picked from commit 4e2e5c1)
taleinat pushed a commit that referenced this pull request May 28, 2021
…onfig_event() (GH-26404)

Since the <Configure> event may occur after the
completion window is gone, catch potential
TclError exceptions when accessing acw.

(cherry picked from commit 4e2e5c1)
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot x86 Gentoo Installed with X 3.x has failed when building commit 4e2e5c1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/464/builds/278) and take a look at the build logs.
  4. Check if the failure is related to this commit (4e2e5c1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/464/builds/278

Failed tests:

  • test_idle

Failed subtests:

  • test_incremental_editing - idlelib.idle_test.test_colorizer.ColorDelegatorTest

Summary of the results of the build (if available):

== Tests result: FAILURE then FAILURE ==

412 tests OK.

1 test failed:
test_idle

14 tests skipped:
test_asdl_parser test_check_c_globals test_clinic test_ctypes
test_devpoll test_gdb test_ioctl test_kqueue test_msilib
test_startfile test_winconsoleio test_winreg test_winsound
test_zipfile64

1 re-run test:
test_idle

Total duration: 32 min 18 sec

Click to see traceback logs
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.11/idlelib/idle_test/tkinter_testing_utils.py", line 54, in new_test_method
    raise exception
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.11/idlelib/idle_test/tkinter_testing_utils.py", line 38, in after_callback
    next(test_generator)
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.11/idlelib/idle_test/test_colorizer.py", line 573, in test_incremental_editing
    eq(text.tag_nextrange('BUILTIN', '1.0'), ('1.0', '1.3'))
AssertionError: Tuples differ: () != ('1.0', '1.3')


Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.11/idlelib/idle_test/tkinter_testing_utils.py", line 54, in new_test_method
    raise exception
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.11/idlelib/idle_test/tkinter_testing_utils.py", line 38, in after_callback
    next(test_generator)
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.11/idlelib/idle_test/test_colorizer.py", line 569, in test_incremental_editing
    eq(text.tag_nextrange('KEYWORD', '1.0'), ('1.0', '1.2'))
AssertionError: Tuples differ: () != ('1.0', '1.2')

@terryjreedy
Copy link
Member

terryjreedy commented Jun 1, 2021

I opened bpo-44282 to follow up on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type-bug An unexpected behavior, bug, or error

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants