Repository navigation
Fix WebView2 Navigate panic and leftover Octop login wall - #17
Merged
Merged
Conversation
Wait until Chromium is ignited before SetURL, recover Navigate panics, and keep WebView2 data on a writable user path. Force ~/.freeos for installed FreeOS, discard stamp-less ~/.octop/portable, and require product=freeos on health so an old Octop host cannot paint the login wall.
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.
Summary
Hotfix for the shipped Windows
v0.0.1installer after PR #16. Opening FreeOS still panicked in Wails WebView2Navigate/SetURLduringsetupChromium/pumpUntilIgnited, and the window that followed was the classic Octop login (red wordmark + slide captcha) instead of a FreeOS local session.A — WebView2 Navigate crash
ICoreWebView2.Navigateran before Chromium was ignited (nil COM), and the hidden settings window was created at the same time as the main window against one UserDataFolder.SetURLretries with panic recovery. Failures show a FreeOS-branded dialog, not a raw Go stack.%LOCALAPPDATA%\FreeOS\WebView2, fallback~/.freeos/WebView2) and setsWEBVIEW2_USER_DATA_FOLDER.B — Octop login wall
~/.octopas the desktop home; it always uses~/.freeosunlessFREEOS_HOME/OCTOP_HOMEis set.~/.octop/portableis discarded. A failed refresh no longer keeps an Octop 0.9/1.0 runtime./api/healthnow includes"product": "freeos". The shell will not treat a leftover Octop process on 8088 as ready; it picks the next free port.?desktop=1is remembered. AuthGuard / Login keep retrying/auth/local-sessionand never show the login form in the Wails shell.Does not change GitHub-only updates, blue theme migration, Organization OS, or uninstall cleanup.
Target branch
main(release/*orhotfix/*only)Type of change
Test plan
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go test -cindesktop/srccompilesproduct=freeos, and leftover~/.octop/portablewipeuv run pytest tests/unit/users/test_local_session.py tests/unit/test_paths.py tests/unit/test_org_module.py tests/unit/desktop/test_auth_brand_surfaces.py tests/integration/test_auth_flow.py -q— passeddesktopShell— 8 passed;npx tsc --noEmitgreenmake precommit+ dashboard build) greenv0.0.1Windows.exeassetsChecklist
CHANGELOG.md(if user-facing)Reinstall for testers
uninstall.exein the install folder).%LOCALAPPDATA%\FreeOS\WebView2and leftover%USERPROFILE%\.octop\portableif an old Octop runtime is still on disk.FreeOS-desktop-windows-amd64-0.0.1.exe/arm64from the refreshedv0.0.1release.%USERPROFILE%\.freeos\portableand skip the login wall.