fadden / 6502bench

A workbench for developing 6502 code
https://6502bench.com
Apache License 2.0
166 stars 33 forks source link

Hang on kbd movement after jump via side window #113

Closed fadden closed 2 years ago

fadden commented 2 years ago

Steps to reproduce:

This causes the app to freeze for a second or so on a medium-size project (larger projects freeze for longer). When it un-freezes it jumps to the top of the file if you hit the up-arrow, or the bottom of the file if you hit the down-arrow. Sometimes the keyboard focus will shift to the Help menu in the menu bar.

The problem is reproducible in every version back to v1.6.0-dev1, but I could not reproduce it in v1.5.0.

The problem doesn't happen if you jump straight to the line using the goto panel. It doesn't matter if the adjacent lines are on-screen or not when you try to move (so it's not a virtual list thing). Scrolling the list with the scroll wheel beforehand doesn't prevent the issue. Clicking on the line at +f07 before using a key DOES prevent the problem.

If, instead of an arrow key, you hit Tab to move between windows, the main window's selection jumps to the line that is just off the top of the screen before shifting the focus to the Symbols window.

The debugger shows it spinning in WPF code, not application code.

I think this is the weird WPF ListView keyboard navigation stuff acting up (again). In particular I think the problem happens when we jump to a new location and the focus was in one of the side windows (Refs, Notes, Symbols), because that's where we double-clicked. Somehow the keyboard focus isn't fully returning to the ListView, and the control is getting confused.

fadden commented 2 years ago

The various side windows have an explicit call to codeListView.Focus(). If I remove that, everything works correctly: focus is immediately returned to the ListView, and the weird hang doesn't happen.

My initial guess would be a clash with the ItemContainerGenerator_StatusChanged stuff, since that's where most keyboard nav bugs seem to originate (the most recent being issue #105). However, that code got rearranged recently, so I would have expected a behavior change. The Focus() calls have been there since v1.2, which is when I switched from WinForms to WPF.

I don't really know why this fixes it, but the Focus() calls are clearly no longer needed. At worst, removing them could cause the focus to remain on the side panel instead of moving to the main window.

fadden commented 2 years ago

Fixed in https://github.com/fadden/6502bench/releases/tag/v1.8.0-beta1