fix: settings window blank in production builds#120
Merged
Conversation
The settings window picked its URL by checking whether build.dev_url was present in the config, assuming it is None in release. It is not: the bundled config carries devUrl from tauri.conf.json verbatim, so production builds pointed the settings webview at http://localhost:1420/settings — a Vite dev server that does not exist on user machines. The page never loaded, the frontend reveal never ran, and reopening from the menu showed a permanently blank window. Gate on tauri::is_dev() instead, so release builds always serve the bundled assets via tauri://localhost/settings (the asset protocol falls back to index.html for SPA routes). Verified in a local release build: the settings webview now loads, renders all panes, and shows itself. Also catches Cargo.lock up to the v0.5.0 version bump (#116), which was committed without regenerating the lockfile. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
libcalibre Test Coverage ReportOverall coverage: 78.94% Coverage breakdown available in the artifacts. |
libcalibre Test Coverage ReportOverall coverage: 80.81% Coverage breakdown available in the artifacts. |
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.
Problem (CDL-15)
In production, opening Settings… showed a window with nothing in it. The settings window chose its URL by checking whether
build.dev_urlwas present in the config, assuming presence means dev. It doesn't: the bundled release config carriesdevUrlfromtauri.conf.jsonverbatim, so production builds navigated the settings webview tohttp://localhost:1420/settings— a Vite dev server that doesn't exist on user machines. The page never loaded, so the frontend reveal (SettingsWindow.tsx) never ran; pressing Settings… again hit the reopen path, whichshow()s the never-loaded window — hence "the window opens, but nothing shows up".Fix
Gate the dev-server URL on
tauri::is_dev()instead ofdev_urlpresence. Release builds now always loadWebviewUrl::App("/settings")→tauri://localhost/settings, served from bundled assets (Tauri's asset protocol falls back toindex.htmlfor SPA routes).Verification
Reproduced and verified in a local release build (
tauri build --no-bundlewith a scratch app identifier and the WebDriver plugin temporarily enabled):http://localhost:1420/settings.tauri://localhost/settings, the window renders all panes (General/Library/Integrations), and reveals itself.Dev behavior is unchanged — the dev branch is the exact prior expression.
Also catches
Cargo.lockup to the v0.5.0 version bump (#116), which merged without regenerating the lockfile.Fixes CDL-15
🤖 Generated with Claude Code