feat: expose wry permission handler API in tauri

[F0RLE]

Description

This PR exposes the expanded wry Permission Handler API through Tauri, allowing applications to intercept and respond to WebView permission requests across supported backends.

It wires the permission handler through tauri-runtime, tauri-runtime-wry, the global Tauri builder, and individual webview builders. Until the matching wry changes from tauri-apps/wry#1654 are released, tauri-runtime-wry points at the merged Wry revision.

Key Changes

• Permission types: Added the expanded PermissionKind and PermissionResponse types to tauri-runtime, mirroring Wry's permission API and platform-specific behavior.
• Global app hook: Added on_permission_request to tauri::Builder, allowing applications to handle permission requests globally for all webviews.
• Per-webview hook: Added on_permission_request to tauri::webview::WebviewBuilder and tauri::window::WebviewWindowBuilder for individual webviews and windows.
• Preserved native defaults: When neither a per-webview nor an app handler is configured, Tauri does not install a Wry permission handler, preserving the existing platform behavior.

Permission Resolution Order

1. Webview-level handler: Checked first when configured for the individual webview.
2. App-level handler: Checked when the webview handler returns Default or is not configured.
3. Wry / OS behavior: A configured handler returning Default delegates to Wry's platform behavior. If no handler is configured, the existing native path is left unchanged.

[github-actions]

Package Changes Through 7efb1bf

There are 14 changes which include tauri with minor, tauri-cli with minor, @tauri-apps/cli with minor, tauri-runtime with minor, tauri-runtime-wry with minor, tauri-utils with minor, tauri-bundler with minor, tauri-build with minor, tauri-macos-sign with minor, tauri-codegen with minor, tauri-macros with minor, tauri-plugin with minor, tauri-driver with minor, @tauri-apps/api with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@tauri-apps/api	2.11.1	2.12.0
tauri-utils	2.9.3	2.10.0
tauri-macos-sign	2.3.4	2.4.0
tauri-bundler	2.9.4	2.10.0
tauri-runtime	2.11.3	2.12.0
tauri-runtime-wry	2.11.4	2.12.0
tauri-codegen	2.6.3	2.7.0
tauri-macros	2.6.3	2.7.0
tauri-plugin	2.6.3	2.7.0
tauri-build	2.6.3	2.7.0
tauri	2.11.5	2.12.0
@tauri-apps/cli	2.11.4	2.12.0
tauri-cli	2.11.4	2.12.0
tauri-driver	2.0.6	2.1.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	cargo/​serde_with@​3.21.0 ⏵ 3.12.0	+13		-10
	cargo/​bytesize@​2.4.2 ⏵ 2.7.0
	cargo/​jsonschema@​0.49.1 ⏵ 0.49.3	+1

View full report

[F0RLE]

Updated this PR after tauri-apps/wry#1654 was merged.

Changes in the latest push:

• merged the current dev branch to resolve the dirty state;
• switched the temporary Wry dependency from my fork to tauri-apps/wry at the merged Wry commit e7c84dc2ee460933a4f61bab3c9f1b2d3d33e337;
• resolved the Cargo.lock conflict.

I also ran cargo check -p tauri-runtime-wry -p tauri-runtime -p tauri --locked locally and it passes.

[Legend-Master]

Let's sign the past commits in this PR first, so we can focus on the actual changes

[y4my4my4m]

These changes would significantly help my project. Thank you for working on it. Hopefully it can be merged soon. Cheers.

[F0RLE]

Done. I rebuilt the PR on top of the latest dev with a signed commit and kept the Wry dependency pointed at the merged tauri-apps/wry commit.

[Legend-Master]

I think you have quite a few merge conflicts that bought back the old code

[F0RLE]

Fixed. The previous rebuild accidentally brought back unrelated tauri-runtime-wry event-loop changes from the old conflict resolution.

[Legend-Master]

We can ignore the apple clippy for now and fix it in another PR with a objc2-* bump maybe paired with a wry bump.

[F0RLE]

One thing I noticed while checking this again: prepare_webview always installs a permission handler wrapper, even when no per-webview or app handler is configured and plugins do not handle the request.

On WKWebView that changes the existing no-handler behavior: no handler uses WKPermissionDecision::Grant, while the wrapper returns PermissionResponse::Default, which maps to WKPermissionDecision::Prompt.

Is that change intended, or should I preserve the old no-handler behavior before this is merged? I can fix it, but wanted to confirm the expected behavior first.

[F0RLE]

Addressed the review feedback in 2bad4b91:

• removed the plugin permission API;
• only install the Wry handler wrapper when a per-webview or app handler is configured, preserving the existing native behavior otherwise;
• moved the runtime permission types to webview_permissions.rs and mirrored the current Wry platform docs;
• updated the WebviewBuilder Android docs;
• added a regression test for the no-handler path.

Local checks:

• cargo test -p tauri --lib --locked (59 passed)
• cargo check -p tauri-runtime-wry -p tauri-runtime -p tauri --locked
• cargo clippy -p tauri-runtime-wry -p tauri-runtime -p tauri --locked -- -D warnings

[Legend-Master]

Thanks! Just a bit of nitpicks and we can get this merged after the wry release

[Legend-Master]

Thanks for the long standing effort!