Cursor creates text selections without dragging the mouse

[n-heartstrings-sterling]

Rubberduck version information Rubberduck version 2.5.2.5906 loading: Operating System: Microsoft Windows NT 10.0.19043.0 x64 Host Product: Microsoft Office x64 Host Version: 16.0.14530.20000 Host Executable: EXCEL.EXE;

Description After (and only after) refreshing using Rubberduck, every second click will inconsistently act as if the mouse is being held down, causing a selection to expand as the mouse moves. On the second click, the selection will remain, A subsequent click will cause a selection to be made towards the cursor, and so on. This only seems to occur in complex user forms.

To Reproduce Steps to reproduce the behavior:

1. Create a new workbook
2. Add a userform
3. Fill it with a about 100 controls - frames, llistboxes, buttons, multipages,,,
4. Handle ten or so click events
5. Fill each handler with thousands of lines of junk. My original file had about 1710 lines of proper code, but I managed to reproduce it using 11,000 lines of For i = 1 To 1 Stop Next instead
6. Compile
7. Refresh using Rubberduck
8. Start clicking about in the code, moving your mouse down and up each time, never holding down click, refreshing again if nothing happens ( It seems pretty inconsistent in this test case, but it's horribly consistent in my original case)
9. The cursor should occasionally act as if you are holding down the mouse button, snapping the selection to wherever your mouse moves despite no input

Expected behavior The cursor should move without making any selections

Screenshots You'll have to take my word for it - at no point during this recording am I holding down the mouse https://user-images.githubusercontent.com/84310111/136296711-4ad6a2db-d87c-42ae-ad5e-80bf69644618.mp4

Logfile Opened existing file with above setup, opened the VBE, refreshed and enabled code explorer, opened userform code, refreshed and clicked around until it occurred once, continued until it occurred a second time, closed file. RubberduckLog.txt

Additional context This is a fresh install of 21H1 and 365 Beta from ODT. I was previously using Windows 10 LTSC with 365 Current without issue. (nb: VBE colors are changed using regedit and changing the palette values in VB7.dll with a hex editor)

[n-heartstrings-sterling]

If I was to take a guess, the issue exists around lines 2337 and 2354 of the log file

2021-10-07 10:29:19.4118;TRACE-2.5.2.5906;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;CancellationTokenSource was already disposed for OnSelectionChange.;
2021-10-07 10:29:19.4118;INFO-2.5.2.5906;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;System.Threading.Tasks.TaskCanceledException: A task was canceled.

Which I figure, as someone who's entirely unfamiliar with the codebase, might imply ignoring the mouseUp event

[retailcoder]

Hm, not sure how that could happen.. these log entries stem from a cancelled attempt (could be because another event came in by the time the handler entered) to update the commandbar labels and commands accordingly with the current selection changing, captured by our OnSelectionChange event... in response to the current selection changing. We do have navigation commands that can alter the current selection in the editor, but none of it seems to be at play here. So that's... interesting.

[n-heartstrings-sterling]

Quick update here - I'm almost certain that it's just plain old lag. When holding down an arrow key, there's a visible stutter. It's worse the more dense the number of calls and expressions.

Here its quite minor, and only really stutters around the assignment operator https://user-images.githubusercontent.com/84310111/136503345-64d7f7b4-0f3b-428e-ba70-37a675982f53.mp4 In a more common case of many chained method calls, it stops constantly (every comma, period, and bracket etc)

I've swapped over to legacy workload configuration, but the performance issues persist. I guess there's some kind of bottleneck? certainly not on the hardware end.

[retailcoder]

Ah, assuming you had the autocompletion features enabled, holding down the arrow key would probably do it - when that's enabled, Rubberduck not only picks up selection changes, but also needs to start handling individual keypresses. Successive arrow-key presses shouldn't be a problem then, but consider using page up/down, mousewheel scrolling, ...or turning off autocompletion in Rubberduck settings: when enabled autocompletion does change a bit how we work in the VBE (esp. with keyboard navigation, and when typing strings and parentheses), and needs a bit of an adaptation to get used to the behavior. Hope it helps!

Edit: actually autocompletion enabled or not holding down any key that affects the current selection would quickly fire up selection changed events, and likely could induce a noticeable lag. OnSelectionChange handlers involve getting the current selection (from the VBIDE API / COM interop), updating the command bar accordingly, and then every menu command needs to evaluate whether it should be enabled or not - that said it doesn't really explain the apparent left-button capture.

[n-heartstrings-sterling]

Yes, as I've found, turning off autocompletion features didn't seem to fix the issue. It's pretty clear that the mouse clicking issue is some kind of lag-induced loss of the mouseUp event through a race condition or similar, but I'm not sure what or how. It's very possible that this issue would occur in an unmodified VBE given the right latency at the right time