* fix(ios): make `init_plugin_*` entry points public so release builds link on Xcode 27
Xcode 27's SwiftPM (Swift Build) gives non-public @_cdecl functions local
visibility in release builds, so each plugin's init_plugin_* is undefined
when Rust links. Mark them public in the 11 plugins with an iOS part.
See tauri-apps/tauri#16130
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Apply suggestion from @lucasfernog
---------
Co-authored-by: takakix2 <1370181+takakix2@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
* Update windows.rs
* Create single-instance-non-unicode-args.md
* fix on linux and windows too
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* feat(shell): add process group spawn option (fix#1332)
Add a `processGroup` boolean option to the shell plugin's spawn command.
When enabled, the child process is spawned in its own process group (POSIX)
or job object (Windows) using the `process-wrap` crate, so that killing
the child also kills the entire process tree.
This fixes the issue where programs like PyInstaller wrappers spawn a
child process that gets orphaned when Tauri kills the parent.
* test(shell): add PyInstaller simulation tests for process group kill
Add end-to-end tests that reproduce the exact scenario from issue #1332:
a wrapper process (like PyInstaller's bootloader) spawns a grandchild.
- Without process_group: killing the wrapper orphans the grandchild
- With process_group: killing the wrapper also kills the grandchild
* refactor(shell): drop redundant cfg gates, trim process-wrap features
Address review feedback on #3351:
- Remove `#[cfg(any(unix, windows))]` gates on `ChildKind::ProcessGroup`,
the kill/pid match arms, and the spawn block, plus the now-dead
`#[cfg(not(any(unix, windows)))]` fallback. That cfg only excluded wasm,
which this plugin never builds for.
- Set `default-features = false` on process-wrap and enable only the
features actually used: std, process-group (unix), creation-flags and
job-object (windows). Drops kill-on-drop, process-session, and tracing.
* fix(shell): enable process-wrap tracing feature, fix CI formatting and changefile
- Add `tracing` feature to process-wrap: with default-features = false its
Windows job_object.rs calls `debug\!` unconditionally while the import is
gated behind `#[cfg(feature = "tracing")]`, failing the Windows build with
"cannot find macro `debug`".
- Reformat process/mod.rs assertions to satisfy `cargo fmt --check`.
- Reindent the process-wrap features array to 2 spaces for taplo.
- Use covector package keys (`shell` / `shell-js`) in the change file so the
check-change-files and covector status jobs pass.
* refactor(shell): unify child handling on process-wrap, drop SharedChild
Collapse the ChildKind enum and the per-platform GroupChild types into a
single process-wrap-backed child. The command always spawns through
StdCommandWrap; the process_group flag is now just an optional wrapper
rather than a switch into a separate child type.
This drops the shared_child dependency and resolves two review notes:
the Unix path no longer hand-rolls killpg, and kill() now goes through
process-wrap's kill (start_kill + wait), which reaps the entire process
group instead of only signalling it.
A background thread polls try_wait to surface the exit status, since
process-wrap's wrappers only expose &mut self wait methods (the reason
SharedChild was used on Unix in the first place).
* chore(example): add process group toggle to shell view
* fix(shell): pass typed creation flags to process-wrap on Windows
`process_wrap::std::CreationFlags` is a newtype over the `windows` crate's
`PROCESS_CREATION_FLAGS`, not a raw `u32`, so the Windows build failed to
compile. Depend on `windows` (already in the tree via `tauri`, pinned to the
same 0.61 that `process-wrap` links against) and use its `CREATE_NO_WINDOW`
constant, which drops the hand-rolled magic number.
The wrap is still required: `JobObject::pre_spawn` calls `creation_flags` and
would otherwise clobber the `CREATE_NO_WINDOW` set at construction.
* perf(shell): block on child exit instead of polling try_wait
The switch from `SharedChild` to `process-wrap` moved the child behind a
mutex, since `StdChildWrapper`'s wait methods take `&mut self` while both
the wait thread and `CommandChild::kill()` need access. A blocking wait
would hold the lock for the child's whole lifetime and starve `kill()`,
so the wait thread polled `try_wait` every 10ms instead.
Block on the raw process outside the lock using a wait that does not reap
(`waitid` with `WNOWAIT` on unix, `WaitForSingleObject` on windows), then
take the lock once to let process-wrap collect the exit status. This is
the same technique shared_child uses internally, applied on top of
process-wrap's kill/reap semantics. No new dependencies or Cargo features
are required.
`kill()` reaps the child while holding the lock, so the raw wait can lose
that race and return ECHILD. That means the exit status is already cached
in the wrapper, so it is treated as success and the status is collected
via `try_wait`. Without this guard, a stress test of 300 spawn+kill
cycles produced 36 Error events in place of Terminated; with it, none in
900 cycles. The `try_wait` loop stays as a defensive fallback, though in
practice the first call succeeds immediately.
Mean latency for `Command::output()` on macOS (debug, 30 iterations of
`echo`) drops from 13.22ms to ~1.8ms, and 10 idle 5s children cost ~11ms
CPU total instead of ~75ms with the poll loop.
* fix(shell): keep CREATE_NO_WINDOW on process-group children (windows)
process-wrap's CreationFlags/JobObject coordination is broken during
spawn (watchexec/process-wrap#35): JobObject::pre_spawn cannot see the
CreationFlags wrapper, so it overwrote our flags with just
CREATE_SUSPENDED and process-group children flashed a console window.
Register CreationFlags(CREATE_SUSPENDED | CREATE_NO_WINDOW) after
JobObject so its pre_spawn runs last and wins. CREATE_SUSPENDED is kept
so the child cannot spawn grandchildren before job assignment; the same
upstream bug keeps wrap_child's resume check from seeing it, so the
child is still resumed.
* test(shell): run the process-tree kill tests on windows
Add a powershell variant of the pyinstaller simulation script and lift
the unix-only gates on the process-group tests, so the windows job in
test-rust exercises the job-object spawn/kill path instead of skipping
it. Both pyinstaller tests now also assert that a Terminated event is
still delivered after kill().
* Update plugins/shell/src/process/mod.rs
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
* Update .changes/shell-process-group.md
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
* Update plugins/shell/src/process/mod.rs
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
* Delete .changes/shell-wait-no-poll.md
* refactor(shell): replace process-wrap with shared_child and an inlined job object
Use std process groups on unix and a job object on windows, with
shared_child handling wait and kill on all platforms.
* fix(shell): kill the process group even after its leader exited
CommandChild::kill returned early once the direct child had been reaped,
so killpg/TerminateJobObject never ran and anything the child left running
in its process group or job object survived, including on app exit.
Adds a launcher-style test (the child starts a grandchild and exits) that
runs on Windows, Linux and macOS.
* fix(shell): restore Debug on CommandChild
Dropping the derive was a breaking change for downstream types that derive
Debug and hold a CommandChild.
* fix(shell): don't block the main thread in the kill command
CommandChild::kill now waits for the child to exit, and the sync kill
command ran it on the main thread while still holding the children lock.
Make the command async and release the lock before killing.
---------
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
In plugins/fs/src/commands.rs, start/stop_accessing_security_scoped_resource
only handled SafeFilePath::Url, so a plain path was a silent no-op
although the JS docs say "path or file:// URL" (and
Fs::stop_accessing_security_scoped_resource accepts paths).
Absolute paths are now converted to file:// URLs first; relative paths keep
being ignored. iOS-only code: formatted but not compiled here (the iOS
tauri build script fails in this environment).
In plugins/fs/src/commands.rs resolve_path / is_forbidden, only paths
that already existed were canonicalized, so a new file below a symlinked
directory in the scope was matched by its unresolved path and written
outside of the scope. Relative symlink targets were resolved against the
process CWD, only the link target was checked against deny patterns, and
resolution errors made is_forbidden fail open.
resolve_path now computes the real path (canonical nearest existing
ancestor + remaining components, following dangling symlinks relative to
their parent, bounded to 40 links) and checks it against the allow and deny
patterns; deny patterns also match the path as given. Resolution errors
fail closed. Unit tests cover symlinked ancestors, relative and dangling
links and loops.
In plugins/fs/android/src/main/java/FsPlugin.kt getFileDescriptor, for
uncompressed assets AssetManager.openFd returns an AssetFileDescriptor
whose parcel descriptor is the whole APK; its startOffset/length were
dropped and Rust read from offset 0, i.e. APK bytes. Only compressed
assets (openFd throws) took the cache copy path.
All assets now use the cache copy path. The cache file path is also checked
to stay below cacheDir/_assets. Kotlin not compiled here: unverified, needs
an on-device check.
In plugins/fs/src/lib.rs on_event, every path dropped onto any window is
added to the global runtime scope, directories recursively, with no
opt-out.
Adds the `scopeDroppedPaths` plugin config option (default true, the
current behaviour) so apps can turn it off. Changing the default or
scoping it per window is deferred to v3.
In plugins/fs/src/android.rs resolve_content_uri, a null `fd` from
getFileDescriptor (openAssetFileDescriptor returning null, e.g. for
virtual files) hit unimplemented!() and panicked inside the command handler.
It now returns an Unsupported I/O error. Also switches the two
io::Error::new(Other, ..) calls to io::Error::other, which clippy flags on
the Android target. Checked with cargo clippy --target aarch64-linux-android.
In plugins/fs/src/lib.rs OpenOptions, custom_flags was deserializable
from the `open` command arguments even though it is not in the TS types,
so a webview with a read-only permission set could pass arbitrary open(2)
flags such as O_TRUNC.
The field is now #[serde(skip)]; Rust callers still set it through
OpenOptionsExt. Rejecting write/truncate/create options of `open` under
read-only sets changes permission semantics and is deferred to v3.
In plugins/fs/src/commands.rs seek, `SeekFrom::Start(offset as u64)`
turned -1 into u64::MAX. The offset is now converted with u64::try_from
and a negative one is an error. E2E spec added.
In plugins/fs/src/commands.rs read_until_bytes / LinesBytes, the line
feed sequence was matched at any byte offset, so UTF-16LE "ਗĀ"
(17 0a 00 01) or UTF-16BE "Āਗ" (01 00 0a 17) split mid code unit and every
following line was decoded misaligned.
Line feed and carriage return sequences now only match on a multiple of
their length from the start of the line. Unit tests with both examples
(they fail without the fix).
In plugins/fs/guest-js/index.ts writeFile, the stream path opened the
file with {write, create} but no truncate, unlike the buffer path which
truncates unless `append` is set (commands.rs write_file_inner), so
shorter content left stale trailing bytes.
The stream path now passes `truncate: !options?.append`. api-iife.js
regenerated. E2E spec covers overwrite and append with a stream.
In plugins/fs/src/commands.rs read, `vec![0; len]` used the length sent
by the webview as is, so a huge `len` aborted the process on allocation
failure, and the whole buffer (not only the bytes read) was sent back.
The length is now capped to the rest of the file (at least 64 KiB) for
regular files and to 64 MiB otherwise, the allocation uses try_reserve so a
failure is an error, and the buffer is truncated to the bytes read. The JS
side only ever used the first `nread` bytes. Unit test for the cap.
* ci: only run what a change affects, consolidate jobs
- detect affected plugins from changed files and Cargo.lock dependency trees
- test/lint Rust per platform in shards instead of one job per plugin
- fold check-generated-files into lint-javascript, fmt into a single job
- skip fat LTO in integration test builds, single ABI in test-android
* ci: run e2e on bumps, use published tauri CLI, PR-safe pnpm cache
- trigger e2e on Cargo/pnpm lockfile and manifest changes
- install the latest 2.x tauri-cli with cargo-binstall in integration tests
- add setup-pnpm action: restore the store everywhere, save only on v2/v3
* fix clippy, ios build
* fix bumps [skip ci]
* feat(notification): report actions on desktop
A click on a notification (tap) or on one of the actions of its action
type now reaches the JavaScript onAction listeners on desktop, and the
new Rust Notification::on_action on every platform. On Linux and the
BSDs the click comes from the notification server's ActionInvoked
signal; on Windows and macOS from notify-rust's wait_for_response,
which needs notify-rust 4.18.
register_action_types, remove_active (Linux and the BSDs) and the
listener commands are implemented for desktop, so they no longer fail
with "command not found".
The api example sends a notification with two actions and shows the
action it hears.
Closes#2150, closes#1903.
* fix(notification): complete desktop action API
* cleanup
---------
Co-authored-by: Haex <hexxx@ok.de>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* fix(ci): Android e2e flakes, shell `Terminated` sent before output
- close "isn't responding" system dialogs before each spec and hide error dialogs on the CI emulator:
a launcher ANR dialog takes input focus from the app, and Android then denies clipboard reads
- retry switching to the webview context until it succeeds instead of running the spec in the
native context when the first switch fails with "No such context found"
- save the focused window, a screenshot and logcat when an Android test fails
- shell: wait for the pipe readers to finish before emitting `Terminated`; the readers took their
read lock on their own thread, so a child exiting quickly could have `close` emitted before
its output
* Apply suggestion from @lucasfernog
* fix(updater): restore the current app when a macOS install fails
On macOS `install_inner` moved the installed app into a `TempDir` backup and
then renamed the new bundle into place. Neither of the two steps after that
move restored the app on failure, and the `TempDir` deleted the backup on
every exit path, so a failed final rename left the user with no app at the
install path and no way back. The privileged fallback had the same shape:
`rm -rf` the app, then `mv` the new one in.
Both moves are now `replace_bundle`, which renames the current app to the
backup, renames the staged bundle into place, and renames the backup back if
that second step fails. The privileged script moves the current app aside,
moves the new one in, and restores on failure; it deletes the previous bundle
only after the new one is in place. The temp and install locations are
compared with `st_dev` before anything moves, returning the existing
`TempDirNotOnSameMountPoint` rather than failing after the app has already
been moved, and the staged bundle root is set to 0755 because `tempfile`
creates it 0700 and that mode followed it into `/Applications`.
Two unit tests cover `replace_bundle`: the staged bundle ends up in place with
the previous one in the backup, and a failed second rename leaves the current
bundle where it was and returns that error.
Closes#3505, closes#3506.
* fix(updater): exchange the current and new bundles atomically on APFS
Even with the restore in place there was a moment between the two renames
where the install path held nothing, and a process killed in that moment
left the previous app in the temp dir rather than where it belonged.
`swap_bundle` calls `renamex_np` with `RENAME_SWAP`, which exchanges the two
directories in one step so the install path always holds one of the two. The
previous app ends up in the extraction temp dir and is removed with it. Where
the file system does not support the swap (`ENOTSUP`, or `EINVAL` on older
systems) the two-rename path with the restore is used as before, and a
`PermissionDenied` from either still goes to the privileged fallback.
`libc` is added for the macOS target only; it was already in the lockfile
through tauri. One macOS test checks the exchange and skips on a file system
that reports `ENOTSUP`.
* fix(updater): keep the previous app when it cannot be restored
If the restore rename also failed, the previous app was left only in the backup TempDir and deleted with it. Keep the backup in that case and return Error::PreviousAppNotRestored with its path.
* fix(updater): quote the paths in the privileged macOS install script
The paths went into single-quoted sh words inside an AppleScript string unescaped, so a quote in the app path broke the command (run as root) or panicked on the compile expect. Quote them for sh and AppleScript, and report script failures instead of panicking.
* fix(updater): fall back to moving the bundles on any swap error
Only ENOTSUP and EINVAL got the two-rename fallback, so volumes reporting EOPNOTSUPP or ENOSYS for RENAME_SWAP failed every update. Fall back on anything but a permission error, and have the swap test skip only off APFS.
* fix(updater): stage the macOS update on the app's volume
When the system temp dir was on another volume than the app, every update was refused. Create the temp dirs next to the app in that case, and compare the install path itself rather than what a symlink there points to.
* test(updater): update a macOS app on another volume than the temp dir
Runs the app from APFS and HFS+ disk images, covering the atomic swap and the two-rename fallback with the update staged next to the app.
* fix(updater): swap the bundles atomically in the privileged macOS install
The admin path ran two mv calls, leaving the install path empty between them. Run renamex_np with RENAME_SWAP as root through osascript's JavaScript bridge, and only fall back to the moves where the swap fails.
* add test
* cleanup
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* chore(autostart): update auto-launch to 0.6
* migrate to `set_macos_launch_mode`
* back to zzzgydi main branch
* use crates.io version of auto-launch
* Add change file
* revert unrelated bumps
github-actions[bot]