Unify Windows shared source for BlazorWebView #4159
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The WebView2 (Windows) code for BlazorWebView had two versions of the code that had drifted apart significantly. In the long term this could easily lead to bugs where only one version is updated and a bug remains in the other.
Why were there ever two versions? The WebView2 types have different identities between WPF+WinForms and WinUI. This means one codebase can't run on both. The original solution was to create abstractions, e.g.
ICoreWebView2
and then implement one for WPF+WinForms, and one for WinUI. That was somewhat acceptable up until the code needed to start diverging dramatically due to WinUI WebView2 having very different patterns for doing file access (100% async), which necessitated having diverging APIs between the two systems. So, the code for the wrappers was copied and modified, creating a divergent implementation.What now? I unified all the duplicated code using shared source and where deviations were necessary, I used my old friend
#ifdef
. It turns out there wasn't that much deviation, but the code is now significantly cleaner because all the WebView2 APIs are called directly instead of via wrappers.Summary: This PR should contain zero functional changes and zero new code paths except for the omission of doing everything through wrappers.