[Problem/Bug]: Changed behavior of CoreWebView2.Navigate since 133

[avendel]

What happened?

Calling CoreWebView2.Navigate with the same URI as the current URI has no effect if a fragment is used (e.g. #param=val). No navigation is performed and the NavigationStarting event is never raised. This behavior has changed with runtime version 133. Prior to that, calling Navigate would always trigger a navigation.

One might argue that navigating to the same uri shouldn't result in navigation. However, the documentation of Navigate indicates that one should expect a navigation to be performed:

Setting _iWebView2.Source will not trigger a navigation if the Source is the same as the previous Source. CoreWebView.Navigate() will always trigger a navigation.

https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.navigate?view=webview2-dotnet-1.0.1587.40

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime), Prerelease (Edge Canary/Dev/Beta)

Runtime Version

133

SDK Version

1.0.1587.40

Framework

Winforms

Operating System

Windows 11

OS Version

No response

Repro steps

Call navigate to open a url:
webView.CoreWebView2.Navigate(new Uri("https://host/#fragment").AbsoluteUri);

Make another call to open the same url:
webView.CoreWebView2.Navigate(new Uri("https://host/#fragment").AbsoluteUri);

This would previously raise a NavigationStarting event, and in 132 (and possibly earlier versions) this would also reload the page. In 133 and 134, no navigation is performed and no navigation starting event is raised.

Note that to reproduce the issue, you must use a fragment (#) in the url. Without a fragment, the NavigationStarting event is raised also in 133-134.

Repros in Edge Browser

Yes. There is a change in how the browser handles user input in the address bar.

In Edge 132, the browser would reload the page when navigating to the exact same url again. In Edge 134 (canary), it will not.

You can easily reproduce this by entering an address, e.g. https://www.bing.com/#fragment in the address bar of chrome. It will load the page. If you put the cursor in the address bar and hit enter, it will reload the page in Edge 132, but not in 134. This behavior is also visible in Chrome using the same chromium versions.

Regression

Regression in newer Runtime

Last working version (if regression)

Runtime 132

[avendel]

Updated the issue description.

To reproduce the issue, you must use a fragment (#) in the url. Without a fragment, the NavigationStarting event is raised also in 133-134. If you add a fragment, e.g. https://www.bing.com/#fragment, the NavigationStarting event is never raised in runtime versions >=133.

Reproduced with SDK versions 1.0.2957.106 and 1.0.1587.40

[avendel]

Minimal reproduction

You can use the program below to see the change by modifying the code to run with different runtime versions, at least until 133 is rolled out in the stable channel.

Enter a url with a fragment in the textbox and click the navigate button. If you do that multiple times, you won't get NavigationStarting or a navigation in >=133.

.NET Framework 4.8.1

Program.cs

internal static class Program {
    [STAThread]
    static void Main() {
        var browserWindow = new BrowserWindow();
        browserWindow.Show();
        browserWindow.Initialize();
        Application.Run(browserWindow);
    }
}

BrowserWindow.cs

public partial class BrowserWindow : Form {
    public BrowserWindow() {
        // Adds a WebView2 control, a textbox for the url and a button to navigate.
        InitializeComponent();
    }

    public async Task Initialize() {
        await this.webView.EnsureCoreWebView2Async(await CoreWebView2Environment.CreateAsync(options: new CoreWebView2EnvironmentOptions {
            ChannelSearchKind = CoreWebView2ChannelSearchKind.LeastStable, // To force use of canary/beta channel including 134.
            // ChannelSearchKind = CoreWebView2ChannelSearchKind.MostStable // to force use of stable channel which is currently 132.
        }));
        this.webView.CoreWebView2.NavigationStarting += CoreWebView2_NavigationStarting;
    }

    private void CoreWebView2_NavigationStarting(object sender, CoreWebView2NavigationStartingEventArgs e) {
        MessageBox.Show($"NavigationStarting event raised (URI = {e.Uri})");
    }

    private void btnNavigate_Click(object sender, System.EventArgs e) {
        this.webView.CoreWebView2.Navigate(this.txtUrl.Text);
    }
}

[ParadoxZero]

I can repro this in Canary runtime. Only HistoryChanged event is triggered.

[avendel]

This behavior change is not limited to WebView2, but can also be seen in the Microsoft Edge web browser.

There is a change in how the browser handles user input in the address bar.

In Edge 132, the browser would reload the page when navigating to the exact same url again. In Edge 134 (canary), it will not.

You can easily reproduce this by entering an address, e.g. https://www.bing.com/#fragment in the Edge address bar. It will load the page. If you put the cursor in the address bar and hit enter, it will reload the page in Edge 132, but not in 134. This behavior is also visible in Chrome using the same chromium versions.

I suspect this was introduced with this chromium change, which landed in 133: https://chromiumdash.appspot.com/commit/0351d764b858cd585f2b0dae27e08e531e091fbb

Related discussion: whatwg/html#10597

[gourabkmsft]

@avendel could you please provide details on the app scenario which is being impacted due to this behaviour change?

[avendel]

@gourabkmsft There are basically two ways this change could affect applications using WebView2:

• Using Navigate to trigger a reload will not work. Applications that have used Navigate to reload the application will be affected.
• Functionality that relies on subscribing to the NavigationStarting event will not work in the situations I described.

What types of problems this could lead to would of course differ between applications. Especially the second point above could be serious if the application has event handler code that needs to be executed for each Navigate invocation, regardless of the url. Imagine for example that an application calls Navigate and then waits for the NavigationStarting event before allowing anything or something else from happening in the application.

[krbharadwaj]

@avendel , could you please share one or two sample scenarios with us to understand the criticality of this issue (change of events)? This will help us expedite this issue further.

[avendel]

@krbharadwaj

We have mitigated the critical issues caused by this change with workarounds for now. There is great value in being prepared for browser updates breaking functionality.

But it is important to understand that releasing fixes to software that uses WebView2 is not always smooth. The type of software that use WebView2 is of course desktop applications running on user workstations, potentially tens or hundreds of thousands, sometimes deployed in ways that require coordination with multiple customers' IT departments.

Here is a scenario of when this change can cause issues:

• An application calls Navigate(url) when the user performs an action in the software, for instance selects an order.
• The application uses fragments (#) in the url to specify which order to open.
• The application prevents other orders from being selected until the NavigationStarting event has been raised after a Navigate has been performed.
• If the user selects the same order as is alredy open, the exact same url as is already opened is passed to Navigate. This could also be a way of refreshing the current view, similar to hitting enter in the browser address bar.
• In this case, no NavigationStarting event is raised, and the application will prevent the user from opening other orders.

This is a scenario where this could result in serious issues with applications using WebView2. The change to the Edge browser could also cause issues for browser users, if they use enter in the address bar to make sure they have fresh information loaded.

I did not find any mentions of this in the release notes of Edge 133. The documentation of Navigate still mentions that:

Setting _iWebView2.Source will not trigger a navigation if the Source is the same as the previous Source. CoreWebView.Navigate() will always trigger a navigation.

...and that

...the corresponding NavigationStarting event is raised sometime after Navigate runs.