fix(mobile): show empty message when pasting an empty clipboard - #5316
Conversation
Tapping paste with nothing copied toasts a file-read error. Classify the paste failure in useClipboardPaste as empty vs unreadable, and have the three paste call sites toast "Nothing to paste" only for the empty case. Denied permission and unreadable image keep the current unreadable copy.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Executive SummaryIncremental review of commit Files Reviewed (4 files)
Previous Review Summaries (2 snapshots, latest commit ce0c52f)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit ce0c52f)Status: No Issues Found | Recommendation: Merge Executive SummaryIncremental review of commit Files Reviewed (1 file)
Previous review (commit b8d5b0a)Status: No Issues Found | Recommendation: Merge Executive SummaryReviewed the empty-vs-unreadable paste classification across the shared hook, both new clipboard probe helpers, and all three call sites; the branch order in Files Reviewed (7 files)
Reviewed by kimi-k3 · Input: 71.3K · Output: 4.6K · Cached: 205.8K Review guidance: REVIEW.md from base branch |
The @sentry/react-native/expo config plugin writes sentry.options.json during expo prebuild. The file duplicates the DSN already tracked in sentry-dsn.js and must not be committed.
hasStringAsync reports true for an empty-string item, so hasClipboardText wrongly classified an empty clipboard as unreadable. Remove hasClipboardText and probe only hasClipboardUrl, which is false for an empty string. An empty clipboard now toasts "Nothing to paste".
pandemicsyn
left a comment
There was a problem hiding this comment.
lgtm. just flagging that the robot pointed there might be a missing helper.
Summary
Tapping paste with nothing copied shows a file-read error ("Couldn't read this file"). The paste hook reported empty, denied, and unsupported-type through one
onUnreadablecallback, so callers could not distinguish an empty clipboard from a denied or unreadable one.The change classifies the paste failure.
useClipboardPastenow reportsonFailure(reason)wherereasonis'empty'or'unreadable'. The three paste call sites toastNothing to pasteonly for the empty case; denied permission and unreadable image keep the current unreadable copy.User: Tapping paste with nothing copied now shows "Nothing to paste" instead of a file-read error. The user can copy and tap again.
Product manager: The empty-clipboard paste case now has a clear, retryable message, distinct from denied permission and unreadable image.
Maintainer:
useClipboardPasteclassifies paste failure as'empty'vs'unreadable'. A newhasClipboardUrlhelper inspects content type only (no iOS paste prompt) and returnsfalseon error. Classification runs after the existing reads;readClipboardTextis not gated on a content-type probe, so URL-only clipboards still paste.Verification
pnpm typecheck,pnpm lint,pnpm check:unusedpass inapps/mobile.git diff --checkis clean.Nothing to paste.Visual Changes
The empty-clipboard paste toast copy changes from "Couldn't read this file" to "Nothing to paste". Denied and unreadable toasts are unchanged. This is a text-only change to a transient toast; no layout or styling changed. The rendered copy was verified by E2E (Appium hierarchy).
Reviewer Notes
pasteno-file branch order is the core logic; review it against the plan's step 2.hasClipboardUrlcatches the AndroidUnavailabilityErrorand returnsfalse.Human steps
No step is needed. No secret, migration, flag, or deploy-order change.