Xamarin.forms: WebView CanGoBack CanGoForward wrong

Created on 26 Sep 2019  ·  9Comments  ·  Source: xamarin/Xamarin.Forms

If a website utilizes the historyApi then the WebView's CanGoBack CanGoForward are wrong.
Steps to reproduce -

  1. Set the webview's source to a single page web application
  2. Navigate within the application to a different url (should utilize the pushstate)
  3. Navigate back -> CanGoForward changes to true
  4. Navigate within the application again by following some link -> CanGoForward erroneously does not change to false

On windows this behavior can be traced to the webview's renderer - https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Platform.UAP/WebViewRenderer.cs
The function UpdateCanGoBackForward is called on different scenarios but none covers updates due to historyApi manipulations.
Registering on the native webview CanGoBack DependencyProperty can resolve this problem as by my tests it is updated to the real state.

webview 3 UWP bug

Most helpful comment

This is still an issue, when will this be addressed?

All 9 comments

@nirbil Can you please attach a small project that demonstrates this issue? Thanks!

On vacation, I'll try in a couple of weeks.
Meanwhile, I bypassed the limitation by implementing custom cangoback/forward properties using custom renderers.
On UWP I've registered on the relevant DependencyProperties and updated accordingly.
On Android I've added registration to DoUpdateVisitedHistory in the FormsWebViewClient and updated the custom properties on each visited history update.
On iOS I have not attempted.

@nirbil Thanks, we'll keep looking for it!

CanGoApp.zip
Attached an example project.
Do the following to reproduce two buggy scenarios:

Scenario 1:

  1. Start either the UWP or Android app
  2. Click the Angular button. The WebView navigates to an angular app page, the Back and Forward buttons are red ✅
  3. Click some link inside that page. The WebView navigates to a different page, the Back and Forward buttons are still red ❌. The Back button should change to green.

If you actually click Back the correct backward navigation occurs.
If you run the same scenario but on step 2 you click Google and then click one of the top links, then the Back button correctly turns green.
This demonstrates how the WebView CanGoBack property is erroneous on sites that utilize the HistoryApi.

Scenario 2:

  1. Start either the UWP or Android app
  2. Click Google. The WebView navigates to google.
  3. Click Angular. The WebView navigates to an angular app page, the Back turns green and the Forward button is red ✅
  4. Click some link inside that page. The WebView navigates to that page.
  5. Click Back. The Forward button turns green ✅
  6. Click some link inside that page. The WebView navigates to that page. The Forward button is green ❌. The Forward button should change to red.

If you actually click Forward nothing happens as a forward navigation is not available.
If you run the same scenario but without navigating using the HistoryApi (basically omitting step 4) then the Forward button correctly turns red.
This demonstrates how the WebView CanGoForward property is erroneous on sites that utilize the HistoryApi.

I have the exact same problem, in my case, it works on iOS as expected but fails on Android.

  • Open a WebPage on a WebView
  • On this page, click on something that calls the method "history.pushState" to register this.

After this, if I check webView.CanGoBack :
on iOS = True
on Android = False

Strangely, if I call webView.GoBack(), it will works as expected on both platforms.

But I need to check if webView.CanGoBack to Show/Hide the Back Button on my UI.

Or if possible webView.GoBack() should return TRUE or FALSE to indicate that some navigation was made. Is that possible?

On Android I've added registration to DoUpdateVisitedHistory in the FormsWebViewClient and updated the custom properties on each visited history update.

@nirbil Could you please share your code with us?

Same problem here.
Custom renderer for Android and CanGoBack in the WebView is always false.

This is still an issue, when will this be addressed?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dannythomas13 picture dannythomas13  ·  56Comments

jassmith picture jassmith  ·  199Comments

Sebastian1989101 picture Sebastian1989101  ·  59Comments

hartez picture hartez  ·  178Comments

hartez picture hartez  ·  59Comments