LeyckerS/moondownloader

Follow-up to #174, which landed its minimal half in #176: web/-only pull requests now get a syntax check (node --check web/app.js). That catches parse errors and nothing else. render_gui.py already exists as a real GUI check — headless-Chromium screenshots that fail on JS runtime errors, element overflow, horizontal scroll, or missing rows. Wired into the same workflow it would gate the class of breakage the syntax check cannot see: code that parses and then breaks the page. What #174 established and what it did not: node --check was verified on the runner. render_gui.py inside a GitHub Actions runner was not — locally it needs pip install -r requirements.txt plus playwright install chromium, and #174 estimated ~1–2 minutes of job time. Whether it runs headless in CI at all, and what it actually costs, is the open question — so this is a problem statement, not a recipe. First step for whoever takes it: get render_gui.py to produce its screenshots in a runner on a scratch branch

Found while re-reviewing #154's counting paths. It exists on main independent of that PR, in both front-ends, so it gets its own issue per the usual scope rule. The accounting A run finishes only when every link is counted. In the CLI: mark_done() bumps n_done and sets all_done once n_done >= len(urls) (moon_cli.py:95-98); each browser_worker exits only on all_done.is_set() and q.empty() (moon_cli.py:183); run() gathers those workers (moon_cli.py:292). The engine is the same shape: mark_done at moon_engine.py:355-358, the worker's exit check at moon_engine.py:216. The dropped path A stall-killed download is re-queued for re-extraction with the same record (moon_cli.py:163-167; engine equivalent in _do_dl), and on pickup the entry is flagged is_re = rec.stall_kills > 0 (moon_cli.py:196, moon_engine.py:231). If that re-extraction then fails: the retry branch excludes it — not is_re at moon_cli.py:260 and moon_engine.py:316; the fail branch excludes it too — not is_re at moon_cli.py:

Both workflows filter by path, and web/ matches neither: .github/workflows/lint.yml triggers on **.py, requirements.txt, constraints.txt, ruff.toml, pytest.ini, .github/dependabot.yml, and itself (lint.yml:3-22). .github/workflows/docs-cli-check.yml triggers on **.md, **.py, and itself. So a pull request touching only web/app.js, web/index.html or web/styles.css arrives with an empty check list: no byte-compile, no lint, nothing. A missing brace in app.js would merge green — there is no green to withhold. #173, the current first-timer issue, even has to warn its taker that "no checks" is normal. The gap is asymmetric with the rest of the repository: #164/#165 established the principle that every file controlling behaviour triggers CI, and the GUI — a third of what users touch — is the one part left out entirely. The minimal gate, verified GitHub's ubuntu-latest runners ship Node.js, and node --check web/app.js parses the file without executing it — verified against current ma

This issue is reserved for someone who has never had a pull request merged on GitHub before. If you have contributed before, please leave it — the roadmap has plenty of other work. (#79, the previous reserved issue, was completed by @FlaggedATX on their first pull request and merged the same day.) There is no programming knowledge required beyond reading three lines. The point is to walk you through fork → edit → pull request once, entirely in the browser. The problem web/app.js converts the same byte counter to "GB" in three places, with two different arithmetics: Line 426 (the phase line): const gb = (m.bytes_total || 0) / 1e9; — decimal gigabytes. Line 449 (the Downloaded card): const gb = (m.bytes_total || 0) / 2 ** 30; — binary gigabytes (GiB). Line 930 (the end-of-run summary): const gb = (m.bytes_total || 0) / 2 ** 30; — binary again. The two conventions differ by about 7.4%, all three readouts say "GB", and the CLI already prints the same quantity as decimal (moon

On a run where 46 of 58 files failed, the GUI's headline card read: COMPLETED 58 / 58 [████████████████████ full green bar] and the pipeline said finished. The card immediately beside it, at a third of the size, read 12 ok · 46 failed. A user glancing at the top of the window sees a completed run. The run was 79% failure. Cause The card is fed by dl_done / dl_total, and _dl_done is incremented on every terminal outcome, not just success — moon_engine.py lines 166, 178 and 194 cover the already-exists, ok and failure paths alike. It is an accurate count of files the engine has finished dealing with; it is displayed under a label that promises something else. The DOWNLOAD 58 / 58 bar in the pipeline section has the same source and the same problem: it fills to 100% in success green regardless of how many of those files exist on disk. The data needed to render this correctly is already in the same snapshot — ok and fail are right ther