From 0b7b6b8157aea0292f2776ed260636c43bb3c7b2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=90=D0=BD=D1=82=D0=BE=D0=BD=20=D0=A2=D1=80=D0=BE=D1=88?= =?UTF-8?q?=D0=B8=D0=BD?= Date: Tue, 29 Sep 2026 00:09:35 +0300 Subject: [PATCH] feat: RAM operations run behind a blocking modal (v3.6.34) A CAP install is a long chain of LOAD commands whose progress and results were only visible at the bottom of a large form - and an interrupted install can leave a half-loaded package. - Server: _RAM_PROGRESS (+ _ram_progress_begin/step/end) records the live step of the running RAM operation; /api/ram-install and /api/ram-install-app wrap their chains in it (total = steps + 1 for the format check) and /api/status carries it as ram_progress - lock-free, so the 2 s poll works while the request holds _CARD_LOCK. - PWA: #ram-op-modal (the STK panel pattern) blocks everything while a RAM operation runs: title, spinner, status line, progress bar, per-step result lines, Close disabled until it finishes; a beforeunload guard protects the window during the run. install-cap, install-app / make-selectable and Explore all use the shared helpers (ramOpModalBegin/Status/Finish); the install results stay in the form area as before once the modal is closed. The status poll feeds the modal via ramOpProgress (headline from the pure ramOpProgressText). - Tests: ramOpProgressText (JS) + the progress lifecycle (Python); the card-state and capmem suites stub the DOM-bound hooks. - Stylesheet rebuilt; version 3.6.34; sw simple-v307. --- frontend/index.html | 107 ++++++++++++++++++++++++- frontend/style.css | 8 ++ frontend/sw.js | 2 +- frontend/tests/card_state.test.js | 3 + frontend/tests/ram.test.js | 12 ++- pyproject.toml | 2 +- pysim_simple_server/server.py | 126 +++++++++++++++++++++--------- tests/test_ota_helpers.py | 17 ++++ 8 files changed, 231 insertions(+), 46 deletions(-) diff --git a/frontend/index.html b/frontend/index.html index 77a242e..cfb45fc 100644 --- a/frontend/index.html +++ b/frontend/index.html @@ -1710,11 +1710,29 @@ + +