fix(window): correct oversized window at >100% scaling + add Maintenance recovery controls#337
Merged
Conversation
…w matches content at >100% scaling #257 forced the webview to 1:1 physical pixels for its physical-px layout, but #326 switched the router's fitWindow to size the OS window with LogicalSize (Tauri multiplies logical px by the OS scale factor). With the webview still rendering 1:1, at >100% Windows scaling the window came out scale-times larger than the content -> the 'window too big, empty space around it' bug. Let the webview devicePixelRatio follow the OS scale so LogicalSize and fitWindow's CSS-px measurements agree and the window matches content at every scaling. Keep --force-text-scale-factor=1 (orthogonal accessibility guard).
…ar WebView2 cache Adds a Settings -> Maintenance section with two recovery controls for the 'window too big / empty space / off-screen' reports: - Reset window position: re-centers the OS window and deletes the persisted tauri-plugin-window-state position (POSITION-only), fixing a window stranded off-screen or at a bad spot. - Clear WebView2 cache: clears the main webview's browsing data (incl. the persisted zoom that can mis-size the window). Confirmed first; does NOT sign the user out (the session lives in the backend HTTP client, not the webview). Backend: system::reset_window_position + system::clear_webview2_cache commands (bindings.ts regenerated). i18n keys added to all three locales.
lshw54
added a commit
that referenced
this pull request
Jul 12, 2026
…resizer (#339) (#341) Windows Accessibility 'Text size' >= 130% clipped the app: #337's '--force-text-scale-factor=1' is not a real Chromium switch and was silently ignored. WebView2 rasterizes at monitor-DPI x text-scale (surfaced as devicePixelRatio) while Tauri LogicalSize only applies monitor DPI, so content painted 1.3x larger than the window at 130%. Fix: derive textScale = devicePixelRatio / (scaleFactor x appliedZoom) at runtime and multiply it into every LogicalSize the resizer emits — big text stays big, the window grows to fit, and text size 100% keeps byte-identical #337 display-scaling behaviour. Drop the fictional flag from lib.rs. 10 new vitest specs; 639 tests + cargo check/clippy pass.
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
Two window issues reported on 6.0.4, both surviving app updates because they
stem from persisted / runtime state rather than the app bundle:
scaling. fix(window): DPI-immune layout, concurrent account fetch, compact AccountList (#255) #257 forced the webview to render at 1:1 physical pixels
(
--force-device-scale-factor=1) for its physical-px layout, but fix(auth): GamePass/reCAPTCHA login fixes (prefill, social login, back-close), flexible DPI window, and account-order persistence #326switched the router's
fitWindowto size the OS window withLogicalSize(which Tauri multiplies by the OS scale factor). With the webview still at
1:1, the window came out
scalex larger than the content.tauri-plugin-window-statepersists the window POSITION, so a window stranded off-screen (or by a
disconnected monitor) restores to that bad spot, and there was no in-app way
to recover.
Fix
--force-device-scale-factor=1so the webviewdevicePixelRatiofollows the OS scale.LogicalSizeandfitWindow'sCSS-px measurements (which already assume
screen.availWidthis CSS px) thenagree, and the window matches its content at every scaling. Keep
--force-text-scale-factor=1(an orthogonal accessibility guard).system::reset_window_positionre-centers theOS window and deletes the persisted
.window-state.json.system::clear_webview2_cacheclears the mainwebview's browsing data (including the persisted zoom that can mis-size the
window). Confirmed first; does not sign the user out (the login session
lives in the backend HTTP client's cookie jar, not the webview).
bindings.ts; i18n keys added to all threelocales.
Notes for reviewers
vitest (629) + production build all pass.
100–200% Windows scaling — there's no scaled display in CI, so this couldn't
be exercised automatically.