panels: sandbox network toggle leaves a pending delete armed across keypresses
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 67/100
Research direction
Start with tui/panels/sandbox_keys.go around line 43 and trace how the sandbox panel handles delete confirmation and the network-toggle key. Check nearby key handling and tests for the expected state transitions. Done when taking the network-toggle action clears any pending delete confirmation, and a later keypress cannot confirm that delete.
Written by the indexing model from the issue text.
Description
Problem
In packages/tui/panels/sandbox_keys.go:43, toggling the network setting does not clear a pending "confirm delete" state that may have been armed by a previous keypress, so the two pieces of UI state (delete-confirmation armed, network toggle) are not properly isolated from each other.
Impact
A user who triggers a delete confirmation prompt, then (without confirming or cancelling it explicitly) presses the network-toggle key, can end up with the delete still armed; a subsequent keypress intended only to continue interacting with the network setting can then be interpreted as confirming the earlier, now-forgotten delete action, destroying data the user did not intend to delete.
Repro
- In the sandbox panel, trigger whatever key arms a pending delete confirmation.
- Without pressing the confirm or cancel key, press the network-toggle key instead.
- Press a key that would normally just continue interacting with the network toggle, and observe the previously armed delete fires instead.
Suggested fix
Clear the pending-delete-confirmation state whenever any other, unrelated action (such as the network toggle) is taken, so a delete can only be confirmed by the key immediately following the one that armed it, never by an unrelated subsequent keypress.
- Dominant language
- Go
- Stars
- 157
- Forks
- 19
- Avg merge
- 4h 4m
- Merged PRs (30d)
- 81
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from solongate/agent-security
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
solongate/agent-security#154 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
solongate/agent-security#147 ·
Maintainers usually reply within 1 day
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
solongate/agent-security#143 ·
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
solongate/agent-security#142 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
solongate/agent-security#140 ·
Maintainers usually reply within 1 day
All issues in solongate/agent-security
Similar issues
-
Handler accepts zero/negative NNCP_MAX_RETRIES and NNCP backoff values, stalling policies or hot-loopingPossibly taken @NopeCharon claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
nmstate/kubernetes-nmstate#1604 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
bug raised-by:desk
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
medici-finance/assay#4723 ·
Maintainers usually reply within 1 day
-
[doc-healer] DDUw improvement: retry integrity-filtered issue reads with direct single-item lookupsOpenautomation documentation
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
flannel-io/flannel#2608 ·
Maintainers usually reply within 2 days