Repository navigation
Conversation
WebView2 is created synchronously: the Windows backend runs the thread's message queue until the environment and the controller report back. It dispatched every message there, the host's among them, while the host was in the middle of the call that waits. A pointer message ran the host's handlers inside that call. Under a Compose scene with a view already attached, that re-entered Compose's dispatcher, which threw, and the window's event loop ended. A wake-up or a request to redraw was lost. Tao sets aside what it receives while its handler is busy and hands it over with the next event, and Nucleus asks for a wake-up or a redraw once and then waits for it. With both taken off the queue during a creation, no next event came: the window stopped drawing and its dispatcher stopped running until something else reached the loop, which on a machine with no one at it is never. The wait now dispatches only what is queued for WebView2's own windows, those of a class whose procedure is in the module its objects come from, and leaves the host's messages queued for the host's loop. A failed creation says on stderr which step failed and with what result.
Each view made a DirectComposition device and a topmost target for the host window. A window takes one topmost target, so only the first view in a window could be created: a second one failed, and with it every screen that shows two views or replaces one with another in the same composition. A window now has one tree, made by its first view and gone with its last, and each view adds its own visual to it. The steps of a creation that can fail after the controller exists say so on stderr too.
…xists GitHub no longer offers the macos-14 runner image, so the macOS native build was cancelled before it started and every job that needs the natives (the JVM tests and the three desktop e2e suites) was skipped. setup-android's default package list still names "tools", which sdkmanager no longer has, so the Android jobs failed in their setup step.
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
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.
Fixes #54, and the failure reported in #55.
The build check cannot pass today, for three reasons. One commit each.
1. The host's messages were dispatched while a view was being created (#54)
WebView2 is created synchronously:
compose_webview_createruns the calling thread's message queue until the environment and the controller have reported back. It dispatched every message it found there, the host's among them, while the host was in the middle of the call that waits.main.The wait now dispatches only what is queued for WebView2's own windows, those of a class whose window procedure is in the module WebView2's objects come from. Everything else stays queued for the host's loop.
2. Only the first view in a window could be created (#55)
Each view made a DirectComposition device and a topmost target for the host window. A window takes one topmost target, so creating a second view in the same window failed with
Failed to create WebView2 (is WebView2 Runtime installed?).A window now has one composition tree, made by its first view and gone with its last. Each view adds a visual of its own to it.
A creation that fails now says on stderr which step failed and with what
HRESULT. #63 reports the same exception for the first view of a window; I do not know its cause, but that line would name the step.3. The workflow asks for what GitHub no longer has
build-natives / macosande2e-macosrun onmacos-14. The native build is cancelled at once (The configuration 'macos-14-arm64-us-default' is not supported), and every job that needs the natives is skipped:common-tests-jvmand the three desktop e2e jobs.setup-android's default package list namestools.sdkmanageranswersFailed to find package 'tools', andcommon-tests-androidande2e-androidfail in that step.common-tests-jvmhas the same step.Both jobs now run on
macos-15, ascommon-tests-iosalready does, and the Android setup installsplatform-toolsonly.Verify
./gradlew :e2e-desktop:runonwindows-latest, one job per tree (run):mainCoroutinesInternalErrorout of Compose's dispatcher within half a minute, then nothing until the step is cancelledmain+ commit 1Failed to create WebView2 (is WebView2 Runtime installed?)main+ commits 1 and 2PR Build Checkwith the three commits, on my fork (run): every job passes.e2e-windows,e2e-linuxande2e-macoseach end with 70 passed, 0 failed.The job was not acquired by Runner of type hosted even after multiple attempts), and the desktop jobs wait behind the macOS native build.e2e-androidfailed C07 and C08 in the first attempt and passed when re-run: both assert the loading state as soon as the page's marker can be read, which can be before Android has reported the page finished. Nothing here touches them.Not changed: Kotlin sources, the macOS and Linux backends.
Left as it is: a creation still blocks the UI thread until WebView2 has started.