feat: add permission handler API across webview backends

[F0RLE]

Description

This PR adds a unified Permission Handler API for intercepting webview permission requests across WebView2, WKWebView, WebKitGTK, and Android.

The API lets applications decide how to handle permission requests at runtime by returning Allow, Deny, Default, or Prompt from a new WebViewBuilder::with_permission_handler callback.

Key Changes

• Added WebViewBuilder::with_permission_handler.
• Added PermissionKind for webview permission categories such as camera, microphone, geolocation, notifications, display capture, MIDI, local fonts, file system access, autoplay, and more.
• Added PermissionResponse with Allow, Deny, Default, and Prompt.
• Added a permission_handler example using permission.site.

Platform Implementations

• Windows (WebView2)

  • Handles WebView2 PermissionRequested events.
  • Maps WebView2 permission kinds to PermissionKind.
  • Applies Allow and Deny; Default and Prompt leave WebView2 default handling in place.

• macOS / iOS (WKWebView)

  • Handles requestMediaCapturePermission.
  • Maps camera and microphone capture requests to PermissionKind.
  • Handles combined CameraAndMicrophone requests by checking camera and microphone separately, with deny taking precedence.

• Linux (WebKitGTK)

  • Handles the permission-request signal.
  • Supports geolocation, notifications, pointer lock, camera, microphone, and display capture where available.
  • Uses is_for_display_device() with the v2_42 feature and falls back to display-capture detection for older WebKitGTK versions.

• Android

  • Handles WebChromeClient.onPermissionRequest and geolocation permission prompts through JNI.
  • Supports camera, microphone, protected media, MIDI, and geolocation requests.
  • Scopes permission handlers per WebView so multi-webview apps route requests to the correct handler.
  • Android runtime permissions may still trigger native OS prompts before access is granted.

Example

cargo run --example permission_handler

[github-actions]

Package Changes Through 954e3e6

There are 1 changes which include wry 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
wry	0.55.0	0.56.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

[pewsheen]

I currently only have a MacBook, so I'll share some thoughts about the macOS implementation here. For WebView2, maybe @Legend-Master can give some advice?

Personally, I tend not to loosen permission controls, to avoid them being used for malicious purposes.

[Legend-Master]

Looks good for the webview2 implementation at least at a glance, awesome work!

Could you also add a change file?

https://github.com/tauri-apps/wry/blob/dev/.changes/readme.md

[Legend-Master]

The webview2 code looks good to me and works well when tested on my computer, just a few small nitpicks, you might need to wait for other members to give some feedbacks on other platforms though

Also, you'll need to sign your commits before we can merge them

[pewsheen]

macOS implementation looks good to me. Only a nit that I think we can improve.

[Legend-Master]

And you'll need to sign your commits

https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

[F0RLE]

The webview2 code looks good to me and works well when tested on my computer, just a few small nitpicks, you might need to wait for other members to give some feedbacks on other platforms though

Also, you'll need to sign your commits before we can merge

Done. The commit is now digitally signed with an SSH key.

[pewsheen]

wkwebview looks good to me 👍 . Let's see if there's something that needs to be discussed in other platform.

[Legend-Master]

Looking good for the webview2 part and general APIs, I'll take a look at the webkitgtk implementation later when I got time. The Android implementation will need someone who's more familiar with the mobile part to review though

Thanks for the patience and awesome work!

Also please don't force push to a single commit on every change, it makes it hard to follow what's changed between each reviews, we will squash merge at the end

[Legend-Master]

I have gone ahead and did some adjustments, hope you don't mind

The Windows and Linux implementations are looking good to me, waiting for a reviewer who's more familiar with the mobile implementations to take a final look before merging

[F0RLE]

Thanks for the review and for the adjustments as well! They look good. Let me know if there's anything else for the Android or webkitgtk implementation.

[F0RLE]

Thanks for the review @FabianLars! Addressed your comments in the latest commit:

1. Combined audio+video on webkitgtk — fixed. Now each permission (mic/camera) is checked individually via is_for_audio_device() / is_for_video_device(). If either is denied, the whole request is denied.

2. WebKitGTK >2.42 — is_for_display_device() is gated behind the v2_42 feature flag. For older versions we fall back to !is_audio && !is_video as a heuristic for display capture.

3. CameraAndMicrophone — on both webkitgtk and macOS/iOS the combined request is now handled by checking PermissionKind::Microphone and PermissionKind::Camera separately, so the handler can grant one and deny the other independently. I think keeping them separate is cleaner than adding a combined variant.