Wrong url on events if using custom_protocol_handler on Windows

[inf9144]

Describe the bug If you register a custom protocol on the builder ("with_asynchronous_custom_protocol") (e.g. "app") you get wrong urls on handlers for navigation ("with_navigation_handler") and page load ("with_on_page_load_handler") on Windows . For an adress like "app://localhost" you receive "https://app.localhost" on your handlers. It happens no matter if you use "with_https_scheme" or not.

Steps To Reproduce Register a custom protocol handler and a navigation handler on windows and open a custom protocol address:

            .with_asynchronous_custom_protocol(protocol, move |request, responder| {
                my_custom_protocol_handler(request, responder)
            })
            .with_https_scheme(true)
            .with_on_page_load_handler(move |event, url| {
               match event {
                   PageLoadEvent::Finished => my_page_load_finished_handler(url),
                   _ => ()
               }
            })
            .with_navigation_handler(move |url| my_navigation_handler(url))

Expected behavior Receive a value ""app://localhost"" instead of "https://app.localhost"

Platform and Versions (please complete the following information): OS: Windows Rustc: Newest

[amrbashir]

So the problem is that on Windows, custom protocols are not really custom protocols and we need to use a workaround, and the actual URL for wry://path/to/page is https://wry.path/to/page.

@wusyong do you think we should fix the URL before passing to these closures or always allow these navigations? what is the behavior of these colsures on other platforms?

[wusyong]

@wusyong do you think we should fix the URL before passing to these closures or always allow these navigations? what is the behavior of these colsures on other platforms?

I think handling this ourselves will be a little more complicated. Not saying it's not it can be, but I guess we can mention this difference in doc comment first. And if anyone would like to open a PR to fix it, we can address the change at that time.

[amrbashir]

@wusyong does with_on_page_load_handler and with_navigation_handler trigger for custom protocols on macOS and Linux?

[J-Cake]

So the problem is that on Windows, custom protocols are not really custom protocols and we need to use a workaround, and the actual URL for wry://path/to/page is https://wry.path/to/page.

@wusyong do you think we should fix the URL before passing to these closures or always allow these navigations? what is the behavior of these colsures on other platforms?

Does anyone actually know why this is the case? The web has always been perfectly cross-platform up until this, what's the difference?

[FabianLars]

Does anyone actually know why this is the case? The web has always been perfectly cross-platform up until this, what's the difference?

WebView2 simply didn't have any APIs that would allow us to register custom schemes until somewhat recently. This wasn't really a limitation of "the web" or even the engine but simply of the webview wrapper. Nowadays it does have the APIs but they were added after they dropped win7/8 support so i think we're waiting until we drop win7/8 support too to switch from http(s) to custom schemes.

[J-Cake]

Does anyone actually know why this is the case? The web has always been perfectly cross-platform up until this, what's the difference?

WebView2 simply didn't have any APIs that would allow us to register custom schemes until somewhat recently. This wasn't really a limitation of "the web" or even the engine but simply of the webview wrapper. Nowadays it does have the APIs but they were added after they dropped win7/8 support so i think we're waiting until we drop win7/8 support too to switch from http(s) to custom schemes.

Ah sick well I hope this gets merged soon. Lemme know if I can contribute anything