fix: a worksheet a lesson downloads comes back as a tab

Some Wonder Ink lesson links are a download rather than a page: the
server sends the PDF as an attachment, so there is nothing for a tab to
show and the file lands on disk.

In this room that is the same as it not arriving. There is no file
manager, no application launcher and no downloads bar, on purpose, and a
teacher is not going to open a maintenance terminal to print a Christmas
tree. 0.2.1 downloaded the worksheet, said so in a notification, and left
it somewhere unreachable. Found on the canary machine with a real lesson.

So a download that completes, and really is a PDF, opens as another tab.
Rendering is the engine's own viewer — the same PDFium Chrome uses — so
there is no second rendering library and no separate application. That
was verified against a completed local file rather than assumed from the
remote case: PdfViewerEnabled was already on, and a local file: URL is a
different question.

WHAT IS REFUSED. A completed download is not a usable worksheet. HTML
that a server called .pdf, an empty file, an unreadable one: all refused
on the first five bytes rather than on the name, because the alternative
is a blank tab that says nothing. An interrupted download says it did not
finish and to try again — and that needed stateChanged rather than
isFinishedChanged, which is not emitted for an interrupted download at
all. Connected to the obvious signal, this said nothing whatsoever about
a worksheet that failed to arrive, which is the one case a teacher most
needs told about. Measured.

WHICH LOCAL FILES. Exactly the ones the window opened itself. Opening a
worksheet adds one resolved path to a list, and the page's
acceptNavigationRequest refuses every file: URL that is not on it.
Chromium already refuses to let a remote page reach file: — verified with
a link, a location.href, and a link to a worksheet that had been
downloaded but not opened by the shell, all refused — so this is the
second lock rather than the only one. It is here because the first one is
somebody else's. Two Qt defaults are turned off beside it:
LocalContentCanAccessFileUrls, which is on by default and would let a
local document read other local documents, and its remote counterpart.
Print to File is removed from the print dialog, because choosing it
enables a path with a "..." button, which is a file chooser, in a room
whose whole design is that there is no file chooser. The PDF viewer's own
menus were audited: two-page view, annotations, present, properties, and
nothing that opens or saves anywhere a teacher chooses.

AND THE BROWSER IS NOT INVOLVED. The handler is connected to Wonder Ink's
own profile, so it only ever sees downloads that started in a Wonder Ink
tab. Nothing inspects a filename, nothing watches a directory, and Chrome
— a separate application with a separate profile — is untouched:
classroom-browser and the Chrome policies are byte-identical to stable
0.2.0. Worksheets go to ~/Downloads/Wonder Ink, which is tidiness and
mostly the security argument: it is the only place one can come from.

Only PDFs. Anything else downloads, says so, and is still unreachable;
that limitation and two small follow-ups are written down rather than
built, and nothing downloaded is ever executed.

Measured from the package on a rebooted machine, and again on one
upgraded from the published 0.2.1: the click-to-tab workflow end to end,
a name with spaces and brackets, multi-page navigation, printing to
Elmer, closing the worksheet without closing the lesson, and the four
refusals. 120 convergence checks and 24 worksheet checks pass on both.
Cookies are still session-only, the Present-view autoplay fix still
works, fullscreen still comes back maximised, and there is still no
address bar and no new-tab button.

Co-Authored-By: Claude Opus 5 <[email protected]>

docs/screenshots/README.md

@@ -44,6 +44,25 @@ browser's other furniture is on the screen.
 | `wonderink-packaged` | the packaged shell against the real app.wonderink.org, launched from the `.deb` on a rebooted machine |
 | `wonderink-disabled` | `WONDERINK_ENABLED=false` — no lesson button, the browser and the disc player where they were |
 
+## Wonder Ink worksheets
+
+0.2.2. A lesson link that downloads a PDF comes back as a tab, and
+nothing else about the room's locks moves.
+
+| | |
+| --- | --- |
+| `pdf-opened` | the worksheet a click downloaded, open as a tab beside the lesson and actually rendered — three pages, not a blank frame |
+| `pdf-page2` | page 2 of 3: multi-page navigation inside the tab |
+| `pdf-spaces` | `Leader Guide, Week 1 (Advent).pdf` — spaces, a comma and brackets, through the download and into a tab |
+| `pdf-print` | printing the worksheet, on the room's own Elmer queue |
+| `pdf-closed-then-page` | the worksheet tab closed, the lesson still there and still working, and an ordinary `target=_blank` tab beside it |
+| `pdf-broken` | HTML the server called `.pdf`: refused on its contents, with a message, and no blank tab |
+| `pdf-interrupted` | a download that did not finish, saying so. The first version of this said nothing at all |
+| `pdf-guard` | three attempts to reach a local file from the page — a link, a script, and a link to a worksheet that was downloaded but not opened by the shell. All refused |
+| `pdf-dotmenu` | the whole of the PDF viewer's overflow menu, audited: two-page view, annotations, present, properties. No open, no save-as, no external link |
+| `pdf-after-save` | the viewer's own download button: straight to Wonder Ink's directory with a notification, no file chooser and no duplicate tab |
+| `pdf-autoplay-preserved` | the 0.2.1 Present-view autoplay fix, still working on the packaged 0.2.2 |
+
 ## Parent Call
 
 | | |

docs/wonder-ink.md

@@ -76,6 +76,112 @@ cut/copy/paste in a text field, print.
 Keys: Ctrl+W closes a tab, Alt+Left and Alt+Right navigate, Ctrl+P prints,
 Ctrl+Tab switches. Ctrl+T, Ctrl+N and Ctrl+L are deliberately unbound.
 
+## Worksheets
+
+Some of Wonder Ink's lesson links are a download rather than a page: the
+server sends the PDF as an attachment, so there is nothing for a tab to
+show and the file simply lands on disk.
+
+In this room that was the same as it not arriving at all. There is no file
+manager, no application launcher and no downloads bar, on purpose, and a
+teacher is not going to open a maintenance terminal to print a Christmas
+tree. 0.2.1 downloaded the worksheet, said so in a notification, and left
+it somewhere unreachable.
+
+So a worksheet that finishes downloading is opened in a tab:
+
+1. a teacher clicks a worksheet link;
+2. Wonder Ink downloads it into `~/Downloads/Wonder Ink`;
+3. when the download **completes**, and the file really is a PDF, it
+   opens as another tab, named after the file;
+4. the teacher reads it, scrolls it, prints it to the room's printer;
+5. closing that tab leaves the lesson exactly where it was.
+
+Rendering is the engine's own PDF viewer — the same PDFium that Chrome
+uses — so there is no second rendering library in the room and no
+separate application. `QtWebEngineSettings.PdfViewerEnabled` was already
+on for remote PDFs; what 0.2.2 adds is opening a *local* one, which was
+verified against a real completed file rather than assumed from the
+remote case.
+
+### What is refused, and why
+
+A completed download is not the same as a usable worksheet, and each of
+these was a real case in the lab:
+
+| | |
+| --- | --- |
+| an interrupted download | the notification says it did not finish and to try again. Nothing opens |
+| HTML that the server called `.pdf` | refused on its first five bytes, not on its name. Without this the teacher gets a blank tab and no reason |
+| an empty or unreadable file | the same |
+| anything that is not a PDF | saved, and said so, exactly as before. Nothing is opened and nothing is executed |
+
+The terminal state is read from `stateChanged`, not `isFinishedChanged`.
+Measured: an interrupted download never emits `isFinishedChanged` at all,
+so the first version of this said nothing whatsoever about a worksheet
+that failed to arrive — which is the one case a teacher most needs told
+about.
+
+### Which local files Wonder Ink will open
+
+Exactly the ones it opened itself, and nothing else.
+
+Opening a worksheet adds that **one resolved path** to a list. The page's
+`acceptNavigationRequest` refuses every `file:` URL that is not on that
+list, so a lesson cannot navigate to one, a link cannot point at one and a
+redirect cannot reach one. Chromium already refuses to let a remote page
+reach `file:` at all — verified in the lab, where a link, a
+`location.href` and a link to a worksheet that *had* been downloaded but
+not opened by the shell were all refused — so this is the second lock
+rather than the only one. It is there because the first one is somebody
+else's.
+
+Alongside it, two Qt defaults are turned off rather than left implicit:
+`LocalContentCanAccessFileUrls` (on by default, and would let a local
+document read other local documents) and `LocalContentCanAccessRemoteUrls`.
+
+The print dialog's **Print to File** option is also removed. Choosing it
+enables an output path with a "..." button, which is a file chooser, in a
+room whose whole design is that there is no file chooser.
+
+### What a teacher still cannot reach
+
+**Anything that is not a PDF.** A lesson handing out a Word document, a
+spreadsheet, a zip of images or a PowerPoint still downloads, still says
+so, and still lands somewhere a teacher has no way to open. This release
+deliberately fixes only the worksheet case, because that is the one the
+room actually hit and because "open whatever arrives" is how an appliance
+stops being one.
+
+The obvious small follow-ups, in the order they are worth doing:
+
+1. **Presentations.** Already planned separately, and the larger of the
+   two jobs — a PowerPoint needs a renderer, not just a viewer.
+2. **A worksheets list.** Not a file manager: one Wonder Ink tab, showing
+   the PDFs already in `~/Downloads/Wonder Ink`, each opening in a tab the
+   same way a fresh download does. It reads one directory, offers no
+   navigation out of it, and needs no new permission — the paths it offers
+   are ones the shell would open anyway. That covers "a teacher closed the
+   worksheet tab and wants it back", which is the next thing that will be
+   asked for.
+
+Neither is in this release.
+
+### Where Wonder Ink's downloads end, and Chrome's begin
+
+They never meet, and not because anything inspects a filename.
+
+The download handler is connected to **Wonder Ink's own profile**, so it
+only ever sees downloads that started in a Wonder Ink tab. Chrome is a
+separate application with a separate profile and its own download
+handling, and nothing here changes, watches or intercepts it. There is no
+directory watcher anywhere in the classroom: a PDF that Chrome downloads
+is Chrome's business and stays that way.
+
+`~/Downloads/Wonder Ink` is a directory of its own inside the ordinary
+Downloads folder. That is partly tidiness and mostly the security
+argument: it is the only place a worksheet can come from.
+
 ## What stayed the same
 
 * **A separate profile from the ordinary browser.** A teacher's Wonder Ink