fix(gui): free the photo viewer and the share dialog when they close

The viewer's handlers held strong references to the viewer and its
window, which own them, so every closed viewer stayed in memory with its
full-size photo. The share dialog's row handlers had the same cycle with
the dialog state. The handlers now hold weak references, and the viewer's
one strong handle is dropped on close with the photo (B241).
This commit is contained in:
nvrl committed 2026-10-16 12:03:02 +02:00
1 parent 5557aa66d5
commit 99707c48fa
3 files changed
+178 -43

No files matched your search

+27
View File
@@ -100,6 +100,7 @@ a live account since.
| Entry | Title |
|---|---|
| [B241](#b241--every-closed-photo-viewer-stays-in-memory-with-its-photo) | Every closed photo viewer stays in memory with its photo |
| [B240](#b240--pdfs-mount-can-be-core-dumped-with-the-keys-in-memory) | pdfs mount can be core-dumped with the keys in memory |
| [B239](#b239----wait-reports-success-for-imports-and-re-dates-that-failed) | --wait reports success for imports and re-dates that failed |
| [B238](#b238--draining-a-large-offline-batch-is-quadratic-in-its-size) | Draining a large offline batch is quadratic in its size |
@@ -343,6 +344,32 @@ a live account since.
Newest first.
### B241 — Every closed photo viewer stays in memory with its photo
**Status:** Fixed, not verified live
**Found:** 2026-10-16, architecture audit (`FINDINGS.md` 2.5.2).
**Where:** `open_photo_viewer` in `crates/pdfs-gui/src/app/pages/photo_viewer.rs`;
`repaint_share_people` and `repaint_share_link` in
`crates/pdfs-gui/src/app/widgets/share_dialog.rs`
**Repro:** Open and close the photo viewer twenty times on large photos, and watch the app's
memory. Or open and close the Share dialog of a shared folder many times.
**Cause.** Every handler of the viewer held a strong `Rc<Viewer>`, and the viewer holds the
widgets those handlers belong to. Several handlers also held the window, which owns them. Each
pair was a reference cycle, so a closed viewer was never freed: not its window, and not the
full-size photo its picture showed. The Share dialog had the same cycle between its state and
the handlers of the rows inside the groups that state holds.
**Fix.** The handlers hold weak handles to the viewer and its window. The one strong handle sits
in the window's close handler, which drops it on close and clears the picture. The Share
dialog's row handlers hold the state weakly too.
**Test:** none automated; the GUI tests run without a display. Checked by reading every handler
`open_photo_viewer` and the share rows connect.
---
### B240 — pdfs mount can be core-dumped with the keys in memory
**Status:** Fixed, not verified live