diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-18 14:07:16 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-18 14:07:16 +0200 |
| commit | c384878aa0d6ef7a33bda23887dc264b94386725 (patch) | |
| tree | 67279ddc7cfbb0902b0cc1348bb66c2724a63d36 /packaging | |
| parent | cf418a095b07c8127042390c748e721d1433879b (diff) | |
| download | meshbay-c384878aa0d6ef7a33bda23887dc264b94386725.tar.gz | |
fix(client): a film can go full-screen, and automatic saving is automatic
**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 <noreply@anthropic.com>
Diffstat (limited to 'packaging')
0 files changed, 0 insertions, 0 deletions