Bug 41760 - WebView Navigated event inconsistent and erroneous
Summary: WebView Navigated event inconsistent and erroneous
Status: CONFIRMED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.1
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-06-13 13:13 UTC by John Hardman
Modified: 2017-06-28 08:02 UTC (History)
5 users (show)

Tags: Xamarin.Forms WebView Navigated event exception ac
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 41760 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description John Hardman 2016-06-13 13:13:25 UTC
Using a WebView in XF 2.2.0.45, the behavior of the Navigated event varies between platforms, and attempting to handle the event at all on Android results in an exception.

Using Xamarin's own WebViewSample, change the URL to be loaded to a URL known to not yet return a page (I put in the URL of a page that will be in my website in future, but that isn't there yet). Now try running the LoadingLabelCode part of the sample.

On Android, when the Navigated event is fired, the following exception is reported. This happens before the webviewNavigated handler has the opportunity to do anything:

06-13 13:54:58.714 I/MonoDroid( 8800): UNHANDLED EXCEPTION:
06-13 13:54:58.716 I/MonoDroid( 8800): System.NullReferenceException: Object reference not set to an instance of an object
06-13 13:54:58.716 I/MonoDroid( 8800):   at WebViewSample.LoadingLabelCode.webviewNavigated (System.Object sender, Xamarin.Forms.WebNavigatedEventArgs e) [0x00000] in G:\xamarin-forms-samples-master\UserInterface\WebView\WebViewSample\WebViewSample\Code Implementation\LoadingLabelCode.cs:44 
06-13 13:54:58.717 I/MonoDroid( 8800):   at Xamarin.Forms.WebView.SendNavigated (Xamarin.Forms.WebNavigatedEventArgs args) [0x0000a] in <filename unknown>:0 
06-13 13:54:58.717 I/MonoDroid( 8800):   at Xamarin.Forms.Platform.Android.WebViewRenderer+WebClient.OnPageFinished (Android.Webkit.WebView view, System.String url) [0x00065] in <filename unknown>:0 
06-13 13:54:58.717 I/MonoDroid( 8800):   at Android.Webkit.WebViewClient.n_OnPageFinished_Landroid_webkit_WebView_Ljava_lang_String_ (IntPtr jnienv, IntPtr native__this, IntPtr native_view, IntPtr native_url) [0x00019] in /Users/builder/data/lanes/3053/a94a03b5/source/monodroid/src/Mono.Android/platforms/android-23/src/generated/Android.Webkit.WebViewClient.cs:231 
06-13 13:54:58.717 I/MonoDroid( 8800):   at (wrapper dynamic-method) System.Object:49c3f8cb-92d1-423d-b1b9-69c270ec5b03 (intptr,intptr,intptr,intptr)


On Windows (both UWP and WinRT 8.1), the Navigated event is fired twice, rather than the expected once. The first time is reports Success, the second it reports Failure. This makes implementing any Success handling error-prone, and largely pointless. The two stack traces for the two firings of the event are as follows (I used my own sample code for these, but it would happen with the Xamarin sample if Windows projects were added):

>	MySample.dll!MySample.WebViewPage._webView_Navigated(object sender, Xamarin.Forms.WebNavigatedEventArgs e) Line 200	C#
 	Xamarin.Forms.Core.dll!Xamarin.Forms.WebView.SendNavigated(Xamarin.Forms.WebNavigatedEventArgs args)	Unknown
 	Xamarin.Forms.Platform.UAP.dll!Xamarin.Forms.Platform.UWP.WebViewRenderer.SendNavigated(Xamarin.Forms.UrlWebViewSource source, Xamarin.Forms.WebNavigationEvent evnt, Xamarin.Forms.WebNavigationResult result)	Unknown
 	Xamarin.Forms.Platform.UAP.dll!Xamarin.Forms.Platform.UWP.WebViewRenderer.OnNavigationCompleted(Windows.UI.Xaml.Controls.WebView sender, Windows.UI.Xaml.Controls.WebViewNavigationCompletedEventArgs e)	Unknown

>	MySample.dll!MySample.WebViewPage._webView_Navigated(object sender, Xamarin.Forms.WebNavigatedEventArgs e) Line 200	C#
 	Xamarin.Forms.Core.dll!Xamarin.Forms.WebView.SendNavigated(Xamarin.Forms.WebNavigatedEventArgs args)	Unknown
 	Xamarin.Forms.Platform.UAP.dll!Xamarin.Forms.Platform.UWP.WebViewRenderer.SendNavigated(Xamarin.Forms.UrlWebViewSource source, Xamarin.Forms.WebNavigationEvent evnt, Xamarin.Forms.WebNavigationResult result)	Unknown
 	Xamarin.Forms.Platform.UAP.dll!Xamarin.Forms.Platform.UWP.WebViewRenderer.OnNavigationFailed(object sender, Windows.UI.Xaml.Controls.WebViewNavigationFailedEventArgs e)	Unknown


On iOS, the Navigated event is fired just the once, as expected, reporting Failure as expected. And Android and Windows implementations should do the same.
Comment 1 John Hardman 2016-06-13 14:30:17 UTC
A further inconsistency is what the WebView actually contains after a navigation Failure.

If the event handlers are not wired up, so that the Android version runs without throwing the exception mentioned above, after a failure the Android version shows a WebView containing 

"Webpage not available

The webpage at [URL here] could not be loaded because:

net::ERR_CONNECTION_TIMED_OUT"

So, even though failure was reported, the WebView contains something (actually, something useful).

On UWP, WinRT 8.1 and iOS, the Webpage is left empty. Given that in the event of a failure, no information is available via the event handlers as to what the cause of the failure was, populating the WebView in the same way that Android does would be useful (and consistent).

All of the platforms should do the same thing in the event of failure. If the event handlers do not provide enough information for developers to tell the end-users something useful, the WebView control should do the same as on Android on the other platforms, so that users do actually get some useful feedback.