From c384878aa0d6ef7a33bda23887dc264b94386725 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Tue, 18 Aug 2026 14:07:16 +0200 Subject: fix(client): a film can go full-screen, and automatic saving is automatic MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit **Full-screen was denied, and the denial was invisible.** The permission handler was written from a true sentence — nothing here needs a camera, a microphone or a location — and implemented as `callback(false)` for everything. Chromium's own video controls ask for the `fullscreen` permission, so a film could not be watched full-screen. What made it hard to find, and what the test now pins: **a denied `fullscreen` does not reject.** `requestFullscreen()` returns a promise that never settles. No exception, no console message, nothing in the renderer that mentions a permission — the button just does nothing. Measured rather than reasoned: the probe reported `NEVER SETTLED` while the main process, instrumented for one run, logged `PERMISSION ASKED: fullscreen`. After the fix the same probe reports `granted` with `document.fullscreenElement` set. The handler now enumerates what is *granted* — `fullscreen`, and nothing else — so a camera, a microphone, a location, notifications and MIDI are still refused and whatever Chromium adds next arrives refused rather than quietly allowed. `Permissions.query` takes the other handler, so both now answer from the one list instead of eventually disagreeing. The old test asserted `callback(false)`, which is to say it locked in the bug. It is replaced by three: what must stay denied, that `fullscreen` is granted, and that both handlers read the same list. **"Save automatically" opened a dialog.** The automatic path required a folder to have been chosen first, and on a new profile nobody has chosen one — so the very first download fell through to Save As, which is the one thing the setting promises not to do. A browser does not make you pick a folder before it will save a file; the system Downloads folder is the answer when there is no other. Verified on a fresh profile with a home of its own: no dialog, 1024 bytes on disk, destination reported as the default (`/home/…/Téléchargements` on this machine, via the localized XDG directory). A folder that *was* chosen and has since gone still asks. Silently redirecting those files is worse than a dialog: someone who picked an external drive wants to be told it is not there, not to find the film in their home directory a week later. Settings shows the effective destination either way, and offers "forget" only for a folder somebody actually chose. 813 tests pass. Co-Authored-By: Claude Opus 5 --- docs/desktop-client-v1.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'docs/desktop-client-v1.md') diff --git a/docs/desktop-client-v1.md b/docs/desktop-client-v1.md index 23287dd..c0bbb90 100644 --- a/docs/desktop-client-v1.md +++ b/docs/desktop-client-v1.md @@ -181,7 +181,18 @@ Electron it is nearly all of it. ### 3.1 What running it changed -Three of the statements above were wrong, and only launching the application found them. +Four of the statements above were wrong, and only launching the application found them. + +**"Nothing here needs a camera, a microphone or a location" was true, and the handler +written from it was still wrong.** Denying every permission also denied `fullscreen`, and +Chromium's own video controls ask for it — so a film could not be watched full-screen. +What makes this worth recording rather than just fixing: **a denied `fullscreen` does not +reject.** `requestFullscreen()` returns a promise that never settles. No error, no console +message, nothing in the renderer that names a permission; the button simply does nothing, +and the operator reported it as "impossible to go full-screen" with no lead to follow. The +probe reported `NEVER SETTLED` while the main process logged `PERMISSION ASKED: +fullscreen`, which is what tied the two ends together. The handler now enumerates what is +*granted* — one entry — so anything Chromium adds later still arrives refused. **The CSP cannot live in a `` tag.** `frame-ancestors` is ignored there — Chromium says so in the console — so a policy carrying it has one directive that silently does -- cgit v1.2.3