feat(windows): add with_native_custom_scheme to use native WebView2 custom scheme registration

[xiaosuawa]

Add native custom scheme support on Windows via ICoreWebView2CustomSchemeRegistration (Runtime >= 110, i.e. Win 10+).
When enabled, custom protocol URLs keep their original format (myscheme://host/path) instead of being rewritten to
http://myscheme.host/path. Falls back to the existing workaround with a warning on older runtimes.

Related issues:

• wry#1129 — wrong URL in event handlers on Windows
• tauri#10667 — Tauri-level feature request for non-HTTP protocols

(Not sure if this opt-in approach fully addresses the issues above.)

Adds two opt-in methods to WebViewBuilderExtWindows and one helper:

fn with_native_custom_scheme(self, enabled: bool) -> Self;
fn with_native_custom_scheme_origins(
    self,
    scheme: impl Into<String>,
    origins: impl IntoIterator<Item = impl Into<String>>,
) -> Self;

pub fn supports_native_custom_scheme() -> bool;

• with_native_custom_scheme(false) (default) — existing behavior

• with_native_custom_scheme(true) — native scheme registration with TreatAsSecure + HasAuthorityComponent; falls back on Runtime < 110

• with_native_custom_scheme_origins(scheme, origins...) — per-scheme SetAllowedOrigins, only effective when native scheme is enabled

• supports_native_custom_scheme() — runtime version check for callers that want to handle the two paths explicitly

Tested with a tao + wry example on my Win 11 PC (Runtime 150) and a Win 7 VM (Runtime 109).

[github-actions]

Package Changes Through 42c2219

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.56.0	0.57.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

[Legend-Master]

This is a bit weird that it allows all those origins to access all custom protocols.

I'm thinking if we should add a custom protocol registry instead of a simple custom protocol handler at this point. cc @FabianLars

(something like https://doc.servo.org/servo/protocol_handler/trait.ProtocolHandler.html, I don't like the fact that this is a trait but you get the idea)

[FabianLars]

The idea back then was to switch the whole thing to custom schemes once webview2 added support for it. It just didn't happen cause of win7 support. Now that we drop that though i'd kinda lean towards that for cross-platform consistency (minus android). And those few usecases that need http/s can use the localhost plugin like they need on macos/linux 🤷

Weird introduction but i wanted to get to "cross-platform consistency" - the other platforms iirc don't have an origin setter so this should probably be handled in the user provided callback?

probably not what you wanted to hear from me lol but i don't see much value in these 2 things - Edit: Or differently, i kinda see the value but i'm tired of adding platform specific shit

[Legend-Master]

This is to allow using the custom protocol in certain origins, for example calling ipc:// in localhost so not possible to do in the callback

On the cross platform note, I somewhat don't want to change it now that seeing the http protocol being more compatible with things, for example the referer and origin headers sent to YouTube for example. Also, we can't change that in tauri or else it breaks the local storage, cookies and all that for existing apps. This is also super problematic if the user was on an older version that didn't support this and updated the WebView to a newer version that supports this.

[FabianLars]

This is to allow using the custom protocol in certain origins, for example calling ipc:// in localhost so not possible to do in the callback

assuming that's how macos/linux do it (can't remember) we can give it a glob to allow all. Or we could add polyfills in the other platforms to do the checks ourselves idk.

On the cross platform note, I somewhat don't want to change it now that seeing the http protocol being more compatible with things, for example the referer and origin headers sent to YouTube for example.

Yeah but we can't fix the other platforms so devs need a workaround anyway, might as well use that on windows. sucks of course so not pushing

Also, we can't change that in tauri or else it breaks the local storage, cookies and all that for existing apps

Sooner or later we have to do that anyway, will send you a dm.

This is also super problematic if the user was on an older version that didn't support this and updated the WebView to a newer version that supports this.

My suggestion included removing the runtime check etc so this wouldn't make a difference, the general min version would be increased to 110 (which virtually every system that is not win7 should have already).

[Legend-Master]

assuming that's how macos/linux do it (can't remember) we can give it a glob to allow all. Or we could add polyfills in the other platforms to do the checks ourselves idk.

That sounds fine to me, I think we can just allow everything as the initial implementation.

(which virtually every system that is not win7 should have already)

Unfortunately I have worked with Windows 11 devices that have older webview2 installed and company policy prevented the auto updates so dropping them completely is not that viable in my opinion.

[xiaosuawa]

I did some testing: SetAllowedOrigins only filters requests before they reach the handler, and CORS still applies normally after that. So I think allowing everything by default and letting the handler deal with it makes sense.
Should I drop with_native_custom_scheme_origins?

[Legend-Master]

If allowing everything works, I'm cool with dropping with_native_custom_scheme_origins.

[xiaosuawa]

Dropped it, now passing "*" by default.