[Feature] Work filePickerPathBaseline down from 7 to 0 #528

New issue

Closed

opened 2026-07-22 10:32:28 +00:00 by brenno · 1 comment

brenno commented

2026-07-22 10:32:28 +00:00

Owner

The gate from #505 landed with a baseline of seven files that take a filesystem path from FilePicker without naming a platform flag themselves. The baseline is a record, not an approval — each entry needs its own decision.

Gated at the caller (4). open_presentation_dialog, slide_finder_dialog, import_slides_dialog, save_destination_dialog. These are correct today: the callers (shell_actions.dart, slide_list_panel.dart", deck_provider.dart`) carry the gate. The file itself cannot prove it, which is exactly the fragility — move the gate into the dialog, or give the dialog a required flag, so the guarantee is local.

Services reading .path (2 files, 5 sites). lib/services/file_service.dart:518,957 and lib/services/image_service.dart:239,265,276. The second is the more interesting: this is the service that maintains mem: keys for browser-held images, so a .path read there is either dead on web or a live blob:-URL leak. Establish which before touching it.

Open bug (1). image_carousel_picker_actions.dart — tracked as #526.

Work them one at a time, each with its own reasoning; do not batch. Removing an entry from filePickerPathBaseline is the proof, and make check-conventions reports a stale entry, so the list cannot rot silently.

The gate from #505 landed with a baseline of seven files that take a filesystem path from `FilePicker` without naming a platform flag themselves. The baseline is a record, not an approval — each entry needs its own decision. **Gated at the caller (4).** `open_presentation_dialog`, `slide_finder_dialog`, `import_slides_dialog`, `save_destination_dialog`. These are correct today: the callers (`shell_actions.dart`, `slide_list_panel.dart", `deck_provider.dart`) carry the gate. The file itself cannot prove it, which is exactly the fragility — move the gate into the dialog, or give the dialog a required flag, so the guarantee is local. **Services reading `.path` (2 files, 5 sites).** `lib/services/file_service.dart:518,957` and `lib/services/image_service.dart:239,265,276`. The second is the more interesting: this is the service that maintains `mem:` keys for browser-held images, so a `.path` read there is either dead on web or a live blob:-URL leak. Establish which before touching it. **Open bug (1).** `image_carousel_picker_actions.dart` — tracked as #526. Work them one at a time, each with its own reasoning; do not batch. Removing an entry from `filePickerPathBaseline` is the proof, and `make check-conventions` reports a stale entry, so the list cannot rot silently.

brenno added the

triage

enhancement

labels

2026-07-22 10:32:28 +00:00

brenno referenced this issue

2026-07-22 11:14:51 +00:00

fix: laat de FilePicker-poort per aanroep kijken in plaats van per bestand #535

brenno referenced this issue

2026-07-22 13:57:31 +00:00

fix: laat de beeldcarrousel via ImageService kiezen in plaats van zelf #559

brenno referenced this issue from a commit

2026-07-22 15:23:00 +00:00

fix(web): poort de bestandskiezer waar hij gelezen wordt (7 -> 2)

brenno referenced this issue from a commit

2026-07-22 15:23:00 +00:00

fix(web): poort de laatste twee bestandskiezers, basislijn naar 0

brenno referenced this issue from a pull request that will close it,

2026-07-22 15:23:02 +00:00

fix: bestandskiezer-poort van 7 naar 0, plus een live webbug (#528) #565

brenno closed this issue

2026-07-22 15:23:20 +00:00

brenno referenced this issue from a commit

2026-07-22 15:23:21 +00:00

Merge pull request 'fix: bestandskiezer-poort van 7 naar 0, plus een live webbug (#528)' (#565) from fix/filepicker-poort-in-de-dialoog into main

brenno commented

2026-07-22 15:23:22 +00:00

Author

Owner

Done in #565 — the baseline is empty.

Each of the seven got its own decision, as asked, and they came out three different ways.

The four caller-gated dialogs were correct today; the gate now sits inside the method, so the file proves its own guarantee instead of borrowing one.

image_service was not a baseline entry but a live bug. The issue asked to establish first whether a .path read on web is dead code or a blob:-URL leak. It is neither: PlatformFile.path throws a bare String there (file_picker 5.5.0, platform_file.dart line 37). Anyone pressing "Bestand kiezen" on a video or audio slide in the web build got an uncaught error, and none of the four callers gated. Two places in check_conventions.dart asserted the blob story — the rule header and the failure message a developer actually reads — and both are corrected with the date and the source.

settings_dialog and file_service hit the class-size ratchet, which turned out to be a hint rather than an obstacle: the gate belonged once per library in a top-level function, not once per picker. FileService 2885 → 2879, locked in.

No test can prove any of this — kIsWeb is always false under flutter test, which is why the gate is static. The proof is the empty list, and make check-conventions reporting a stale entry itself (which it did three times on the way, each time confirming a fix had landed).

Closing.

Done in #565 — the baseline is empty. Each of the seven got its own decision, as asked, and they came out three different ways. **The four caller-gated dialogs** were correct today; the gate now sits inside the method, so the file proves its own guarantee instead of borrowing one. **`image_service` was not a baseline entry but a live bug.** The issue asked to establish first whether a `.path` read on web is dead code or a blob:-URL leak. It is neither: `PlatformFile.path` **throws** a bare String there (file_picker 5.5.0, `platform_file.dart` line 37). Anyone pressing "Bestand kiezen" on a video or audio slide in the web build got an uncaught error, and none of the four callers gated. Two places in `check_conventions.dart` asserted the blob story — the rule header and the failure message a developer actually reads — and both are corrected with the date and the source. **`settings_dialog` and `file_service`** hit the class-size ratchet, which turned out to be a hint rather than an obstacle: the gate belonged once per library in a top-level function, not once per picker. `FileService` 2885 → 2879, locked in. No test can prove any of this — `kIsWeb` is always false under `flutter test`, which is why the gate is static. The proof is the empty list, and `make check-conventions` reporting a stale entry itself (which it did three times on the way, each time confirming a fix had landed). Closing.