fix(app): stop the process-list refresh from stomping on scroll position and typed input

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).

[JeanExtreme002]

Closes#75.

The picker's 3 s auto-refresh — and, it turned out, its Filter box and its own click handling — could take the user's scroll position, their typed input, and even their choice of process. All of it lives in one small cluster of handlers in open_process_dialog.py.

1. The scroll position (the issue)

Each tick restored the previously selected row with QTableView.selectRow. That moves the current index, and QAbstractItemView::currentChanged scrolls the view to the current index — so once the user had clicked any row, the list jumped back to that row on every tick and scrolling through a long process list was impossible.

Measured offscreen with 300 rows: click row 2, scroll to offset 150, one refresh tick → offset 2.

The fix takes the scroll offset before the model is rebuilt and puts it back after the selection is restored. Rebuilding the model is not the problem on its own — Qt defers the scrollbar range update, so the offset survives setRowCount(0) plus 300 appendRows (150 before, 150 after, with no selection). That is why the restore has to sit after the selectRow call rather than merely around the rebuild.

Two alternatives were rejected:

• Restoring the selection with selectionModel().select() instead, so the current index is never moved. It does preserve the scroll position, but it leaves the current index invalid after every tick, which costs keyboard navigation.
• Anchoring on the top visible row's PID and using scrollTo(..., PositionAtTop). More exact — restoring a raw ScrollPerItem value is a row index, so the view drifts by one row when a process sorting above the viewport starts or exits — but the picker now matches the save/restore pattern already used in threads_dialog.py, modules_dialog.py and memory_map_dialog.py. Worth revisiting for all four at once if the drift ever matters.

The auto-refresh itself is kept: the issue also suggests dropping it in favour of the existing Refresh button, but with the viewport preserved it no longer interrupts anyone.

2. The typed process name

Restoring the selection emits selectionChanged, and _on_selection_changed mirrored the selected PID into the "Process:" field unconditionally. Click a row, type a process name, and 3 s later the field held the old PID again — so pressing Enter opened the process that was clicked instead of the one that was typed. Against a live process list the typed text survived 1.7 s.

This one needed the click first: typing without ever selecting a row was always safe, and the Filter box at the top was never affected, which is why it went unnoticed.

The echo is right for a click and wrong for a refresh, so the restore now runs inside _programmatic_selection(), and _on_selection_changed ignores selection changes made under it. Blocking the selection model's signals instead would also have suppressed the view's own repaint of the row it just selected.

3. Clicking a row that is already highlighted

_try_open only ever reads the entry, and clicking a row that is already selected emits no selectionChanged in single-selection mode — so nothing re-synced the entry. Fixing (2) is what made this reachable: before, the next tick overwrote the entry and papered over it.

Reproduced with real mouse events: click a row (entry becomes 1296), type a name, let a tick restore the selection, then click that same highlighted row — the entry still says notepad.exe while the row for 1296 is selected, and Open Process opens the name. With an emptied entry, the same click leaves Open warning "Type a PID or process name first" while a row sits highlighted.

clicked now aims the entry at the row it carries, and _on_row_activated (double-click) reuses that step before opening. A real double-click emits clicked then doubleClicked — verified by delivering the four mouse events — so the entry is aimed on the first release and _try_open still runs exactly once.

4. The Filter box retargeting the selection

Hiding the selected row does not clear the selection: Qt remaps it onto whatever row took that index. Measured — pick pid 1179, type a name, filter to proc12, and the entry reads 1129, a process the user never chose; the next tick then cements it. The remap is now refused (the selection is dropped when the filter hides it, kept when it doesn't) and neither the remap nor that cleanup reaches the entry.

Tests

New tests/app/test_open_process_dialog.py, following the conventions in test_auto_refresh_dialog.py (module-scoped qapp, offscreen platform, the enumeration worker stubbed out so the live process table can't land mid-test). Ten tests covering: the #75 repro (asserting the restored selection stayed outside the viewport, not just the scrollbar number), the selection surviving a tick, the typed name surviving a tick, a click and an arrow-key pick both still filling the entry, a click on the already-highlighted row re-aiming it without opening anything, the double-click opening the row it carries, the filter dropping a hidden pick instead of retargeting it, the filter keeping a visible one, and a tick under an active filter finding the picked PID among the filtered rows.

Each fix was mutation-checked: dropping the scroll restore, clearing the selection on any filter keystroke, swallowing every echo, un-wiring clicked, wiring clicked to the open path, and giving doubleClicked its old index-discarding lambda back each fail the tests that cover them.

tests/app is 113 passed; mypy and flake8 are clean. The 15 failures in the full suite are pre-existing macOS permission failures, unrelated (same 15 on a clean tree).