Problem
On single-button boards, some actions bound to a KEY_ENTER long-press execute immediately on detection, with no confirmation and no way to undo. This currently affects at least the SHUTDOWN page (powers off as soon as the button is released) and the WIFI/BLUETOOTH transport toggle where present (flips a persisted preference immediately, reboots once released). A single accidental long-press (device bumped in a pocket, a glove or finger slipping, or simply holding the button a bit longer than intended) is enough to trigger either.
Concrete reproduction (confirmed on real hardware)
Manually entering bootloader mode (hold PRG/GPIO0, tap RST while held) requires holding PRG continuously for at least the duration of the RST tap. On Heltec Wireless Tracker V2 (using the stock 1000ms long-press threshold shared by 61 of the 62 boards in this repo, not an accelerated one), this reliably exceeds the threshold well before RST is tapped. So simply entering bootloader mode, with no intent to change any setting, silently triggers whatever long-press action is bound to the current home page. Confirmed on more than one board in this port.
Impact
No visual warning beyond the normal press feedback, and the change (a persisted preference flip, or a power-off) takes effect immediately or at the next reboot, with no way to know it happened until you notice.
Proposed direction
A hold-to-confirm pattern for this class of action: a first long-press arms a pending state (shown on screen, e.g. "hold to confirm"), a second long-press within a short window actually executes it, and navigating away or letting the window expire cancels without effect. This kind of two-step confirmation for destructive single-button actions is a well-established pattern elsewhere. I have a working implementation of this for the SHUTDOWN page and the WIFI/BLUETOOTH transport toggle. Happy to open a PR if this approach sounds reasonable.
Message sequence on the BLUETOOTH page, switching BLE on while WiFi is on
Message sequence on the WIFI page, switching WiFi on while BLE is on
Result of the sequence above: WiFi enabled
Message sequence on the SHUTDOWN page (hibernate)
(Generated with Claude Code)
Problem
On single-button boards, some actions bound to a KEY_ENTER long-press execute immediately on detection, with no confirmation and no way to undo. This currently affects at least the SHUTDOWN page (powers off as soon as the button is released) and the WIFI/BLUETOOTH transport toggle where present (flips a persisted preference immediately, reboots once released). A single accidental long-press (device bumped in a pocket, a glove or finger slipping, or simply holding the button a bit longer than intended) is enough to trigger either.
Concrete reproduction (confirmed on real hardware)
Manually entering bootloader mode (hold PRG/GPIO0, tap RST while held) requires holding PRG continuously for at least the duration of the RST tap. On Heltec Wireless Tracker V2 (using the stock 1000ms long-press threshold shared by 61 of the 62 boards in this repo, not an accelerated one), this reliably exceeds the threshold well before RST is tapped. So simply entering bootloader mode, with no intent to change any setting, silently triggers whatever long-press action is bound to the current home page. Confirmed on more than one board in this port.
Impact
No visual warning beyond the normal press feedback, and the change (a persisted preference flip, or a power-off) takes effect immediately or at the next reboot, with no way to know it happened until you notice.
Proposed direction
A hold-to-confirm pattern for this class of action: a first long-press arms a pending state (shown on screen, e.g. "hold to confirm"), a second long-press within a short window actually executes it, and navigating away or letting the window expire cancels without effect. This kind of two-step confirmation for destructive single-button actions is a well-established pattern elsewhere. I have a working implementation of this for the SHUTDOWN page and the WIFI/BLUETOOTH transport toggle. Happy to open a PR if this approach sounds reasonable.
Message sequence on the BLUETOOTH page, switching BLE on while WiFi is on
Message sequence on the WIFI page, switching WiFi on while BLE is on
Result of the sequence above: WiFi enabled
Message sequence on the SHUTDOWN page (hibernate)
(Generated with Claude Code)