-
Notifications
You must be signed in to change notification settings - Fork 55
Javascript call opens browser on Android #166
Comments
There is no plan for blazor to implement the browser history api in the IUriHelper. See dotnet/aspnetcore#12838 |
Hi ! I have made some code on each supported platforms in order to allow WebView navigations to be catched when detected, allowing you to create your own business app logic, like opening external resource outside your app, allowing the navigation request, or denying it. It's like the regular Xamarin.Forms OnNavigating event on WebView (and even, i use the same interface internally), the only difference is that i reimplemented the logic on extra platforms (like ElectronNET, and Android because we use GeckoView instead of the OS Browser at runtime). The other difference is that iframe navigation will also be detected and forwarded, that can be nice too. The OnNavigating event is totally programmable by yourself. Then go back to me if this fixed your issue, i will then close it. |
Forgot to mention that the browser opening behavior you are having now may be because of the default handler implementation shipped within the template. Just put a break point while debugging on Android in your OnBlazorWebViewNavigationHandler.cs file (or another if you create yourself a new one), and inspect the values coming when your navigation occur. |
I'll try that and post the result when finished |
So on navigation the events url is "http://127.0.0.1:8888/code/B" Template default behavior:
When url starts with base url we should maybe do nothing instead of starting the device's browser. Thank you for helping out. Nice work! Keep going on i'm sure this will be the future of client applications. |
Actually, the original line should be right in a Blazor scenario. When navigating through your Blazor application, your browser is not "really" navigating, that would mean a full page navigation instead. That's why when you go from one page to another, even if the URL is different, this handler is not called. If the event here has been fired this mean that while you have navigated backward with your code, the browser asked for a real page navigation. This may be not what your expecting, as it mean a full reload of the page. But i don't know what your code is doing. Be just aware of the meaning of this event handler. Thanks for the congrats ! Some very cool features (and fixes) are coming in a release tomorrow or sunday (i wish), like switching loaded app, storing and loading downloaded app... It will allow to easily update your app in the background without having your user going to the app store if you like, at least if your "native" codebase have not changed or does not impact your Blazor app runtime ! |
Very nice. Hyped to see it. But that means when the url is starting with the base url, you want to navigate with the device's browser? So when url starts with 127.0.0.1 we know that's inside the app, i mean who would want to call a localhost address in the device browser? So this means that JS call to window.history.go(-1) calls a "real navigation". So since blazor doesn't support navigating back currently (afaik see issue mentioned above), how to do this in a nice way (I don't want to pass through the origin destination). |
Yes of course, it may be not a problem at all, i was just saying that this navigation is a side-effect you don't have when navigating through your gestures on the phone (clicking buttons etc..). And so, will this behave as smooth as expected, or the same ? Also, i may not be aware of all side effects of the "navigating" event of every browser. Can you confirm me that if you use window.history.go(-1), your app don't reload completely ? Thanks for your questions ! |
Navigating back seems to not reload completely. I'm sure there's a trick to find out. I'm new to blazor so can you tell me how to find out? Can i find out by overriding OnInitialized on the MainLayout component? |
If everything is ok, go ahead in my opinion, with your current behavior. You have multiple "tricky" way to do this, one would be to inherit all you "page" objects from an extended base model, that would cache the current rendered page. Another would be to try if you can listen to the javascript history change, or if window.location.href change , and store the value. You will surely find more solutions on the net. In the end, if you have the previous url (and parameters as well if possible), you may use the navigation manager of Blazor, and try to navigate to the page from the informations you know. But as i said, if everything is working properly, don't make it complicated yet. Just manage the "false positive" in the WebViewNavigationHandler and go ahead. |
Okay then. Thank you very much for helping out. Changing the navigation handlers behaviour to not start a browser resolves the issues. You are right, i could use the navigation manager of Blazor BUT that would mean i have to pass through the origin destination to every site with back navigation enabled. I can't understand why they don't want to implement the back navigation in browser history to their interface. But if that is their decision (by design as they say), i keep going on with the js interop workaround as many Blazor users do atm. Have a nice evening ;) |
Thanks ! You too ! |
As I expected, the navigation bug with window.history.go is related to Webextension and onbeforerequest events on it. Someone found this behavior here too: piroor/newtabfromlocationbar#18 (comment) so it’s specific to Webextension modules (and in our case, Android) |
Hi,
on the top bar i have a back button. I couldn't find a nice way to navigate back with blazor, so i used a js call to do so.
My component has the following elemtn:
<img class="top-row-left" src="assets/ionicons/chevron-back-outline.svg" alt="<" onclick="window.history.go(-1)" />
In the BlazorMobile project this is working fine, while in android it's opening chrome with the last link, which should open in the web view inside the app.
I don't know if this is a bug or by design. Would be nice to find a solution for my back navigation problem though.
The text was updated successfully, but these errors were encountered: