-
Notifications
You must be signed in to change notification settings - Fork 64
Description
What happened?
In our application we use the approach documented here https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/working-with-local-content?tabs=dotnetcsharp#loading-local-content-by-handling-the-webresourcerequested-event.
Basically we avoid saving the PDF content to disk, choosing instead to feed it directly as a stream to WebView2 to render it.
This used to work perfectly until about a week ago when some sort of change in the ecosystems (Edge, Windows, Defender) broke it.
It appears whatever this change is , it was gradually rolled out. Our customer machines started acting up about a week ago. My machine was not affected until yesterday, Dec 13 and the only updates I could see were some Windows security updates and security intelligence definitions. I tried rolling things back to pinpoint a culprit but to no avail.
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
143.0.3650.80
SDK Version
1.0.3650.58
Framework
WPF
Operating System
Windows 11
OS Version
26200.7462
Repro steps
I am attaching a WPF solution / project that illustrates the issue. It uses a WebView2 control to render content from a stream. The WebView2 control is configured to use the bin\Debug\net8.0-windows\ as the user data folder.
Compile and run it with the defaults and you'll notice the window comes up, flickers from white to black to white but no PDF content is displayed.
Setting breakpoints in the ManagedStream will tell you that the control is fully reading the stream.
If you check out the bin\Debug\net8.0-windows\EBWebView\Crashpad\reports you will see dmp files.
If you open the dmp file and try to see what happened you'll see a stack trace like the one in the MsEdgeCrashStack.txt file in the root of the project.
There are a few open Chromium issues that appear related to the method at the top of the stack GetOriginForURLLoaderFactoryAfterResponse: https://issues.chromium.org/issues?q=GetOriginForURLLoaderFactoryAfterResponse
Change the UseCustomScheme from true to false and run. You'll now notice that the PDF content is rendered, albeit after quite a sizeable delay compared with what we used to experience when the custom scheme was working.
This issue seems specific to PDF content because trying to render HTML from a stream seems to work in both scenario (custom scheme or not)
.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Regression in newer Runtime
Last working version (if regression)
No response