[bug] macOS: App crashes with SIGABRT when dragging file with missing path during drag-enter

[soundtemple]

Describe the bug

Tauri Bug Report: macOS Drag-Drop Crash with Missing Files

Summary

Tauri app crashes with SIGABRT when dragging a file with a missing/invalid path onto the interface. The crash occurs during drag-enter validation, before the drop event, and happens in Tauri's native code.

Environment

• OS: macOS 15.6.1 (24G90)
• Architecture: ARM-64 (Apple Silicon)
• Tauri Version: 2.9.4 (latest)
• Tested Versions: 2.5.1, 2.9.4 (both crash)

Reproduction

Steps to Reproduce

1. In my case files are dragged on to my app from another DJ app or Music.app (e.g., Rekordbox) that has a song reference where the file no longer exists
2. Drag that song from the DJ app onto the Tauri app window
3. App crashes immediately (before mouse is released, during drag-enter)

Technical Details

• The crash occurs when macOS's drag handling calls -[NSDragDestination _draggingEntered]
• This triggers Tauri's native code to validate file paths
• When an invalid/missing path is encountered, Tauri's code calls abort()
• This happens before the tauri://drag-drop event, so application-level error handling cannot prevent it
• The abort bypasses Rust's panic handling

Expected behavior

Expected Behavior

App should handle missing file paths gracefully by:

• Skipping invalid paths and continuing
• Showing an error message
• Not crashing

Actual Behavior

App crashes with EXC_CRASH (SIGABRT) - abort() called

tagami_crash_report.rtf

Additional Context

• This affects any drag operation with invalid file paths (e.g., from other apps where files have been moved/deleted)
• The issue is specific to macOS drag-and-drop handling
• Application-level error handling cannot prevent this crash
• The bug persists across multiple Tauri versions (2.5.1 → 2.9.4)

Related

• This appears to be a bug in Tauri's native drag handling code
• The abort() call should be replaced with proper error handling that returns an error instead of crashing

Full tauri info output

npm run tauri info

> tagami@0.71.0 tauri
> tauri info


[✔] Environment
    - OS: Mac OS 15.6.1 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ Xcode: 26.1.1
    ✔ rustc: 1.87.0 (17067e9ac 2025-05-09)
    ✔ cargo: 1.87.0 (99624be96 2025-05-06)
    ✔ rustup: 1.28.2 (e4f3ad6f8 2025-04-28)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 22.2.0
    - yarn: 1.22.17
    - npm: 10.7.0

[-] Packages
    - tauri 🦀: 2.9.4
    - tauri-build 🦀: 2.5.3
    - wry 🦀: 0.53.5
    - tao 🦀: 0.34.5
    - @tauri-apps/api  ⱼₛ: 2.9.1
    - @tauri-apps/cli  ⱼₛ: 2.9.5

[-] Plugins
    - tauri-plugin-fs 🦀: 2.4.4
    - @tauri-apps/plugin-fs  ⱼₛ: not installed!
    - tauri-plugin-dialog 🦀: 2.4.2
    - @tauri-apps/plugin-dialog  ⱼₛ: not installed!
    - tauri-plugin-notification 🦀: 2.3.3
    - @tauri-apps/plugin-notification  ⱼₛ: not installed!
    - tauri-plugin-store 🦀: 2.4.1
    - @tauri-apps/plugin-store  ⱼₛ: 2.4.1
    - tauri-plugin-log 🦀: 2.7.1
    - @tauri-apps/plugin-log  ⱼₛ: not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:5173/
    - framework: React
    - bundler: Vite

Stack trace

## Crash Details
- **Exception Type**: `EXC_CRASH (SIGABRT)`
- **Termination Reason**: `abort() called`
- **Crash Location**: 
  - Frame 17: `-[NSDragDestination _draggingEntered]` (macOS AppKit)
  - Frames 3-16: Tauri's Rust code calling `abort()`
- The abort happens in Tauri's compiled code during drag-enter validation, before application code can intercept

## Stack Trace (Key Frames)

Thread 0 Crashed:: main Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib         __pthread_kill + 8
1   libsystem_pthread.dylib        pthread_kill + 296
2   libsystem_c.dylib              abort + 124
3-16 app                            [Tauri's Rust code - abort() call]
17  AppKit                         -[NSDragDestination _draggingEntered] + 40
18  AppKit                         NSCoreDragTrackingProc + 804

Additional context

No response

[FabianLars]

would it be possible to get the full stacktrace? some of your assumptions are not 100% correct and i'd like to see if the stacktrace includes a hint as to where exactly it fails. I know which couple of lines are relevant here but would be cool to know which one exactly before diving in.