fix(windows): surface the failing HRESULT on webview creation failure - #14
Merged
Y-PLONI merged 3 commits intoAug 28, 2026
Merged
Conversation
createInAppWebViewEnv now passes the failing HRESULT to its completion handler, and all three callers append it to the error returned to Dart. In release builds debugLog is compiled out, so a creation failure reached the host as a bare "Cannot create the InAppWebView instance!" with no way to tell an access denial from an unsupported composition path. getHRErrorString reports the hex code alongside the system message, since the message text is localized and often generic. This also fixes a hang: a synchronous failure of CreateCoreWebView2Controller / CreateCoreWebView2CompositionController never invoked the callback, so the MethodResult was never completed and the Dart caller waited forever. WindowsWebViewCreationFailures broadcasts the failure to the host application. Creation fails before any webview object exists, so there is no callback to hang this on, and the only symptom was a blank area plus an unhandled async error.
The default 5s DISCOVERY_TIMEOUT killed --gtest_list_tests mid-print on a cold CI runner, failing the build before any test ran.
palmoni5
force-pushed
the
fix/windows-creation-failure-hresult
branch
from
August 27, 2026 22:26
764b5f3 to
7bdd355
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Problem
In release builds
debugLogis compiled out (#ifndef NDEBUG), so whencreateInAppWebViewfails the host only ever sees:The actual
HRESULT— already checked byfailedAndLoginsideInAppWebView::createInAppWebViewEnv— is discarded. A recent field investigation (plugins failing to load on a Windows-on-ARM machine, where the app runs x64 under emulation and the composition-controller path is refused) needed several rounds of remote diagnostics that a single HRESULT would have answered immediately.Changes
createInAppWebViewEnvpasses the failingHRESULTto its completion handler; the visible, headless and in-app-browser callers all append it to the error they return.getHRErrorStringinlog.hreports the hex code next to the system message, because the message text is localized and often generic.CreateCoreWebView2Controller/CreateCoreWebView2CompositionControllernever invoked the callback, so theMethodResultwas never completed and the Dart caller waited forever. Both paths now report it. This also removed the duplicated callback bodies between theControllerOptionsand legacy branches.WindowsWebViewCreationFailuresbroadcasts creation failures to the host. Creation fails before any webview object exists, so there is no per-widget callback to hang this on — until now the only symptom was a blank area plus an unhandled async error, with no way for the host to render its own message.Verification
flutter testpasses influtter_inappwebview_windows(the native-source assertions innative_creation_failure_cleanup_test.dartwere updated, and a new test covers the failure broadcast).flutter build windowsof the consuming app (Otzaria) compiles the changed native code.Context: Otzaria/otzaria#1016, Otzaria/otzaria#1014.