fix(macos): use modern pasteboard API for drag-drop file collection#1723
Open
vdavid wants to merge 1 commit into
Open
fix(macos): use modern pasteboard API for drag-drop file collection#1723vdavid wants to merge 1 commit into
vdavid wants to merge 1 commit into
Conversation
Switch `collect_paths` to `NSPasteboard.readObjectsForClasses:options:` with `NSURL`, which covers both legacy `NSFilenamesPboardType` and the modern per-item `public.file-url` type (the standard for sources using `NSDraggingItem.initWithPasteboardWriter:` with `NSPasteboardItem`). This also removes the panic when the source publishes only the modern type: `availableTypeFromArray:` reported the legacy type was derivable but `propertyListForType:` returned nil, hitting an `unwrap` and crashing the webview process. The new code has no `unwrap` calls — failures skip the entry. The legacy `NSFilenamesPboardType` branch is kept as a defensive fallback.
Contributor
Package Changes Through 545b7abThere are 1 changes which include wry with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
vdavid
added a commit
to vdavid/cmdr
that referenced
this pull request
May 6, 2026
- New `native_drag.rs` builds `NSPasteboardItem`s vending `public.file-url`, `public.utf8-plain-text` (joined paths on item 0), and `NSFilenamesPboardType` (legacy, for stock wry until tauri-apps/wry#1723 ships) - Permissive op mask (Copy|Link|Generic|Move) so terminals like Warp accept the drop instead of rejecting it; macOS arbitrates the actual op via modifier keys natively - Drops `drag` + `tauri-plugin-drag` Rust deps and `@crabnebula/tauri-plugin-drag` JS dep; both drag-out paths (single-file and multi-file selection) now route through `native_drag.rs` via `start_drag_paths` / `start_selection_drag` - Removes the `mode` parameter from drag IPC end-to-end — modifier handling belongs in the OS, not at drag-start
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
2 participants
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.
On macOS,
collect_pathsreads dragged file paths from the deprecatedNSFilenamesPboardTypeonly. When the drag source publishes only the modern per-itempublic.file-urltype (the standard forNSDraggingItem.initWithPasteboardWriter:withNSPasteboardItem),availableTypeFromArray:reports the legacy type as derivable butpropertyListForType:returns nil, hitting anunwrapand panicking the whole webview process.This switches
collect_pathsto the modernNSPasteboard.readObjectsForClasses:options:API withNSURL, which covers both legacy and modern sources in one call. The legacyNSFilenamesPboardTypebranch is kept as a defensive fallback in casereadObjectsForClasses:options:returns nothing on some configuration. Nounwrapcalls anywhere in the new code — every fallible conversion skips the entry instead of panicking.Test plan
I did these:
cargo buildandcargo testonaarch64-apple-darwinandx86_64-apple-darwin, with default features,--all-features, and--no-default-features --features os-webview. All combinations: 8 unit tests + 6–7 doc tests passed, 0 failed.cargo clippy --all-targets --all-features, it's clean (existing unrelatedexamples/gtk_opengl.rsunused-import warnings only, present ondevsince docs: add gtk opengl triangle example #1682).cargo fmt --all -- --checkclean.public.file-urltypes (noNSFilenamesPboardType), self-drag re-entry into the wry webview no longer panics — thereadObjectsForClasses:path returns the URLs andcollect_pathsyields the expectedVec<PathBuf>.