Repository navigation
feat(mobile): attach and scan through the system’s own picker sheet - #584
Merged
Merged
Conversation
On a phone, "Attach file" and "Scan a card or document" each opened a custom bottom sheet asking where the file comes from, and the scan one stacked a second sheet over the Add picker. Both are gone: each action now opens the webview's own file input, which iOS answers with its Photo Library · Take Photo · Choose File sheet and then the matching system picker, on the first tap. - `elements/FileInput`: the hidden input, shared by both actions. No `capture`, so the sheet offers the camera rather than skipping to it. - What the sheet hands back is a `File` with no path, so it travels as bytes: scans through the existing `scan_image_bytes`, attachments through a new `attachment_add_bytes` (body = file, entry id and percent-encoded name as headers). Sealing is shared with the path route (`seal_bytes`), the name is kept to its last path component, and the per-file cap is checked before the bytes are copied, and in the webview before they are even read. - The `photo` pick kind, the `scanSource` store state and the four sheet strings are removed from Rust, the store and every locale. - Docs: the compact-shell convention and the threat model's bytes paragraph.
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
The system file-input sheet always offers Take Photo whenever it offers the photo library, and a file to attach is one the user already has. So Attach file asks with an action sheet of its own — Photo Library, Choose File, Cancel — drawn the way the platform draws one (`elements/ActionSheet`: centred rows in a floating group inset from the edges, a separate Cancel pill, no grabber, close button or chevrons), and each answer runs the matching system picker from Rust as before. Scan keeps the system sheet, where the camera belongs. The bytes route for attachments is withdrawn with it: `attachment_add_bytes`, the store and API wrappers, and the `percent-encoding` dependency.
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
…lace The phone asks where a photo or a file comes from with one sheet, `elements/SourceSheet` — Take Photo · Photo Library · Choose File — for both Scan and Attach, so the two read as one surface and the Add picker's own sheet. It never stacks on that picker: the scan row closes the picker and opens the sheet in its place, as Receive does. The rows are the Add picker's `ActionRow`, now with the mark in the accent's soft tile and a 36px tile on the phone, and the sheet ends 8px under its card rather than 20. Each row opens the system's own picker: the camera through the webview's capture input (bytes, as before), the library and Files through the Rust dialog and its grants — `pick_file` takes `browse` to ask a phone for the file browser under the image filter, and the `photo` kind is back for an image to attach. A picker backed out of leaves the question open; a photo taken or a file picked answers it. A lock drops the sheet with the rest of the session's UI (`resetUi`), which is what the system's own file-input sheet could not do: WebKit presents it outside the DOM and offers no way to dismiss it, so it stayed over the lock screen. A system picker already up is the OS's and outlives the lock until dismissed; what it hands back is dropped, since the session that asked is gone.
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
The frame padded its body by the safe-area inset plus 24px, and the body padded itself again, so a three-row source sheet ended in a 65pt band of empty ground — a third of its height. The frame now keeps the system's own clearance (the inset plus 8px); what a body needs beyond that it pads itself. The Add picker takes the same cut.
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
The source sheet opened on 64px of ground before its title, 4px between the header's hairline and the rows, and 66px under them. Now every bottom sheet keeps one rhythm: a 32px grabber row (the close standing 6px proud of the card's edge to keep its 44px target), the heading 8px under it — a framed `DialogHeader` takes the same 8px, so the Add picker matches — 16px from the description to the card, 16px from the card to the home indicator, 20px gutters. The source sheet drops the hairline: the card is the separation.
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
The scrim, the grabber and Escape are the ways out, as on the system's own sheets; the icon was a fourth, and the only thing in the grabber row's corner. What a screen reader cannot do is tap a scrim or swipe a grabber, so the row keeps a Close control for it alone, out of sight until it has focus.
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
The rows wore the Add picker's `ActionRow` — a grey tile under the mark and a chevron — which says "a way in to somewhere", while each of these does something: opens a picker, takes a photo. They are now `MenuRow`, the row of the system's own action menus: the label leading at the body size, the symbol trailing at 20px in the same ink, no tile, no chevron, 52px tall, the card's hairline between. `ActionRow` goes back to what the Add picker had, since its rows do lead somewhere.
Contributor
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
On a phone, Attach file and Scan a card or document each opened a custom bottom sheet asking where the file comes from, and the scan one stacked a second sheet over the Add picker (see the screenshots in the thread). Both custom sheets are deleted. Each action now opens the webview's own
<input type="file">, which iOS answers with its system sheet — Photo Library · Take Photo · Choose File — and then the matching system picker, on the first tap. It is the sheet Safari, Mail and every web-based app on the phone show, with the system's Cancel to back out.How
elements/FileInput: one hidden input shared by both actions. Nocaptureattribute, so the sheet offers the camera rather than skipping straight to it;accept="image/*"for the scan, unrestricted for attachments.Filewith no path, so it travels to Rust as bytes. Scans go through the existingscan_image_bytes. Attachments go through a newattachment_add_bytes: the file is the request's raw body, the entry id and the percent-encoded file name are headers. Sealing is shared with the path route (seal_bytes), the stored name is kept to its last path component, and the per-file cap is checked before the body is copied in Rust and before the file is even read in the webview (so a 2 GB video is refused without being loaded).photopick kind inpick_file, thescanSourcestore state, and the four sheet strings from every locale.Verified
bun run typecheck,bun run lint,bun run build,bun run test(1088 passing),cargo fmt --check,cargo clippy --all-targets -D warnings,cargo test(862 passing). Theaarch64-apple-ios-simclippy job could not run in the agent sandbox (SwiftPM's ownsandbox-execis refused there); the Rust change has no platform-specific code, so the host run covers it.Not in this PR: a VisionKit document-camera plugin (edge detection, flattened multi-page scans). It needs a Swift Tauri plugin that cannot be built or verified from the sandbox.
Decisions
scan_image_bytes,attachment_add_bytes), with no path grant. — The bytes are already the webview's own, so neither command can be made to read anything it did not.capture. — It would skip the system sheet and lose the photo-library and Files routes that shipped in feat(scan): let a phone scan from the camera or the photo library #578.