Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong url on events if using custom_protocol_handler on Windows #1129

Open
inf9144 opened this issue Dec 24, 2023 · 3 comments
Open

Wrong url on events if using custom_protocol_handler on Windows #1129

inf9144 opened this issue Dec 24, 2023 · 3 comments

Comments

@inf9144
Copy link

inf9144 commented Dec 24, 2023

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
Copy link
Member

amrbashir commented Dec 27, 2023

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
Copy link
Member

wusyong commented Dec 31, 2023

@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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants