2 seconds delay is seen with Page navigation using WebView2 & SetVirtualHostNameToFolderMapping

[sowrab1994]

Description
When we load a local page using SetVirtualHostNameToFolderMapping and the domain is non-existent we see a 2 secondsdelay in the page navigation to complete.

Version
SDK: 1.0.1185.39
Runtime: 100.0.1185.44
Framework: WPF
OS: Win10

Repro Steps

1. Create a sample WPF Application
2. Create WebView2 instance and add it to a WPF grid.
3. Set CoreWebView2.SetVirtualHostNameToFolderMapping to a virtual host name and folder consisting of sample HTML page.
4. Register NavigationStarting and NavigationCompleted events and log the timestamps.
5. Load the sample HTML Page inside the WebView.
6. Run the application.

Note that the page loads after 2 seconds delay. That can be seen by taking the difference in timestamps logged in NavigationCompleted and NavigationStarting events.

Workaround
If we add a host file entry mapping valid IP address (machine's IP) and virtual hostname (provided in SetVirtualHostNameToFolderMapping), the page loads fine without any delay.

Additional context
It looks like it is trying to reach the host and causes the timeout.

AB#39415297

[santoshsampath]

Couple of other points:

• We can always see DOMContentLoaded fires exactly after around 2s (in dev tools using performance.getEntries())
• If we load directly using file:/// path it is always quick. But we want to load using virtualhost so that we can take advantage of all Web APIs, some of which are not available with file:/// origin

[david-risney]

Yes it looks like there's still a part of the code trying to resolve the hostname. Good bug thanks!

If you pick a name that causes hostname resolution to just wait and timeout after 2s you'll see that when navigating to a SetVirtualHostNameToFolderMapping URI. For example, if you use app.local or anything .local you'll see this behavior. As a workaround if you pick the special TLD *.example, like app.example hostname resolution should go very quick without hitting the network and no 2s timeout issue.

[VAllens]

Couple of other points:

• We can always see DOMContentLoaded fires exactly after around 2s (in dev tools using performance.getEntries())
• If we load directly using file:/// path it is always quick. But we want to load using virtualhost so that we can take advantage of all Web APIs, some of which are not available with file:/// origin

Thank you so much. :)

I spent 4 hours using Edge DevTools to study why the DOMContentLoaded event is always triggered after a delay of 2 seconds. It drives me crazy!

file:// can solve my problem !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
My issue is the same as that raised here.

But i did not use SetVirtualHostNameToFolderMapping.
I use AddWebResourceRequestedFilter and WebResourceRequested.
After getting the request, I get the stream from the assembly embedded resource and respond to it.

[VAllens]

After changing to file://, the delay is shortened from 2 seconds to 16 milliseconds, which is a tremendous progress.

[david-risney]

The SetVirtualHostName and file: URIs are handled by the browser process. The WebResourceRequested event raises its event to you on the WebView2 UI thread in your host app. This means the WebResourceRequested event will be potentially much slower because it has a second process hop and it has to wait for the UI thread to be available. If all you need is to access local files, SetVirtualHostName or file: URIs are a better option than WebResourceRequested. But if you need the flexibility of providing your own custom stream then WebResourceRequested is required.

[VAllens]

Yes, I embed all static resources(html, js, css, png, etc...) into assembly resources.
So I need to custom handle requests and responses in WebResourceRequested event.

[bzuillsmith]

Thank you Allen Cai (@VAllens) for the suggested workaround using file://. It worked great! Just so no one is confused, it's not an issue of WebResourceRequested taking a long time because of interprocess communication that's happening. It's also not an issue of the initial load of the control. When using the WebResourceRequested event, the browser shows the file is downloaded in very few ms (the interprocess communication is done). Then it waits until the 2s mark to actually render. There were no other indicators in the dev tools as to what was taking so long.

Also note that using NavigateToString is extremely fast and I can even load the entire google.com search page in 1.2s. It's only the WebResourceRequested approach that has this issue, possibly only when using a real looking http(s) url.