When a flash flow is running on either tab (DapLink unlock/erase/program or Wireless Stack operator+FUS+WS), the window's CloseRequested event is processed unconditionally in src/ui/main_window.rs: settings are saved and the window is closed via iced::window::close. The OpenOCD child process or the serial worker is then dropped mid-operation, which can leave the target in a half-flashed state.
This is more of a UX / safety nicety than a bloquant — for an internal tool the user is usually paying attention — but worth mentioning because the failure mode (half-erased flash, FUS interrupted mid-upgrade) requires a recovery sequence on the next try.
The webusb reference tool (steami-tools/webusb-wireless-stack) has no equivalent guard since it's a web page; we have a free hand here.
Possible approaches
- Block close: ignore
CloseRequested while tab_daplink.is_readonly or tab_ws.is_readonly is true.
- Confirm dialog: prompt "A flash is in progress. Quit anyway?" via
rfd::AsyncMessageDialog.
- Cancel + close: best-effort kill the OpenOCD child and break out of the WS state machine before closing.
The simplest is probably option 2 — non-destructive, gives the user the choice.
Tracked from the stack_flash review, item #12.
When a flash flow is running on either tab (DapLink unlock/erase/program or Wireless Stack operator+FUS+WS), the window's
CloseRequestedevent is processed unconditionally in src/ui/main_window.rs: settings are saved and the window is closed viaiced::window::close. The OpenOCD child process or the serial worker is then dropped mid-operation, which can leave the target in a half-flashed state.This is more of a UX / safety nicety than a bloquant — for an internal tool the user is usually paying attention — but worth mentioning because the failure mode (half-erased flash, FUS interrupted mid-upgrade) requires a recovery sequence on the next try.
The webusb reference tool (steami-tools/webusb-wireless-stack) has no equivalent guard since it's a web page; we have a free hand here.
Possible approaches
CloseRequestedwhiletab_daplink.is_readonlyortab_ws.is_readonlyis true.rfd::AsyncMessageDialog.The simplest is probably option 2 — non-destructive, gives the user the choice.
Tracked from the stack_flash review, item #12.