fix(classic): drive the portal even when the page never finishes loading (issue #356) - #362
Open
lshw54 wants to merge 1 commit into
Open
fix(classic): drive the portal even when the page never finishes loading (issue #356)#362lshw54 wants to merge 1 commit into
lshw54 wants to merge 1 commit into
Conversation
…ing (issue #356) Follow-up report: with hardware acceleration OFF no portal window appeared at all, and with it ON the window appeared but never clicked GamaPass by itself. The first half is the environment mismatch already fixed in 3e4eb44 — and the hardware-acceleration correlation confirms that diagnosis independently: turning it off adds --disable-gpu / --disable-gpu-compositing to the main window's browser args, which the portal did not inherit, so its environment no longer matched the shared user data folder and WebView2 refused it (ERROR_INVALID_STATE). With acceleration on, both sides happened to be wry's defaults, so it worked. That fix landed AFTER the v6.0.10 tag, so the reporter's build does not have it. The second half is this commit. Every step waited for readyState "complete", which waits for EVERY subresource — one hung request (an analytics script an accelerator / VPN / blocker swallows, a slow CDN) meant the gate never opened and no step ever ran: the sign-in click, the consent, the account selection, all of them. The window just sat there, which is exactly what "it doesn't click GamaPass by itself" looks like. The gate now falls back to URL stability after ~5s and posts a ready-timeout message naming the document state and href, so the same situation is diagnosable from the log instead of looking idle. 1025 Rust tests, 681 frontend tests, clippy clean under -D warnings.
Closed
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
1 participant
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.
What
Follow-up on #356. The reporter narrowed it down precisely:
Two separate problems, and the first one confirms an earlier diagnosis.
1. No portal window with hardware acceleration off — already fixed, not yet released
This is the WebView2 environment mismatch fixed in
3e4eb44, and the hardware-acceleration correlation is independent confirmation of it:--disable-gpu --disable-gpu-compositingERROR_INVALID_STATE→ no webviewEvery WebView2 environment sharing a user data folder must be configured identically; the portal reused the per-instance folder but not the args, so turning hardware acceleration off was exactly what made the two diverge. The fix has the portal inherit the main window's args.
It landed after the v6.0.10 tag, so the reporter's build does not contain it — the next release does.
2. Never clicks GamaPass by itself — fixed here
Every step in the portal script waited for
document.readyState === 'complete', which waits for every subresource. One hung request — an analytics script an accelerator / VPN / content blocker swallows, or a slow CDN — and that state never arrives, so the gate never opened and no step ever ran: the sign-in click, the consent, the account selection, all of them. The window just sat there looking alive.The gate now falls back to URL stability after ~5 s (the URL has been unchanged that whole time, so the document we can see is the one we are going to get) and posts a
ready-timeoutmessage naming the document state and href, so the same situation shows up in the log instead of looking idle.Checks
1025 Rust tests, 681 frontend tests, clippy clean under
-D warnings, fmt clean.