fix(window): compensate Windows text-size scaling in the content-fit resizer#341
Merged
Conversation
…resizer Windows Accessibility 'Text size' >= 130% clipped the app again after #337. The '--force-text-scale-factor=1' switch #337 kept as a guard is not a real Chromium switch (zero matches in the Chromium source) and was silently ignored. The text scale reaches the webview through WebView2's rasterization scale (monitor DPI x text scale), surfaced as devicePixelRatio, while Tauri's LogicalSize multiplies by the window's monitor-DPI scale only — so at 130% text size every CSS px paints 1.3x larger than the logical px the window was sized in, clipping content by exactly that ratio. Fix: derive textScale = devicePixelRatio / (windowScaleFactor x appliedWebviewZoom) at runtime and multiply it into every LogicalSize the resizer emits. Big text stays big (unlike #257's forced 100% webview scale), the window grows to fit, and at text size 100% the ratio is 1 so #337's >100% display-scaling behaviour is untouched. - services/windowFit.ts: scale tracking + clamped textScaleFactor() (dependency-free, unit-tested; clamp [1,3] rejects transient and Ctrl-zoom-out readings) - router/index.ts: track Window.scaleFactor()/onScaleChanged, multiply the factor into fitWindow and resizeWindow sizes, record applied zoom - lib.rs: drop the fictional --force-text-scale-factor flag; only set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS when args exist - tests: 10 new specs for textScaleFactor
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.
What
Windows Accessibility "Text size" ≥ 130% clips the app again on 6.0.5 (regression of the problem #257 originally fixed, reported in #339). #337 removed #257's
--force-device-scale-factor=1to fix the oversized-window bug at >100% display scaling and kept--force-text-scale-factor=1as a text-size guard — but that switch does not exist in Chromium (zero matches in the Chromium source), so it was silently ignored and nothing guarded against text scaling.Root cause of the clipping: WebView2's rasterization scale is
monitor DPI scale × system text scaleand is surfaced to the page asdevicePixelRatio, while Tauri'sLogicalSizemultiplies by the window's monitor-DPI scale only. At text size 130%, one CSS px paints 1.3× larger than the logical pxfitWindowsized the window in — content overflows the window by exactly that ratio.Fix
Have both: keep #337's correct display-scaling behaviour AND respect the user's enlarged text (instead of #257's approach of forcing the webview back to 100%, which defeated the accessibility setting).
Derive the text scale at runtime —
— and multiply it into every
LogicalSizethe content-fit resizer emits. The window simply grows to fit the enlarged text. At text size 100% the ratio is 1, so behaviour at every display scaling is byte-identical to #337.src/services/windowFit.ts— scale tracking + clampedtextScaleFactor()(dependency-free, unit-tested). Clamp to [1, 3]: Windows text size spans 100–225%, so out-of-band values (transient mid-resize readings, persisted Ctrl-zoom-out) fall back to 1.src/router/index.ts— trackWindow.scaleFactor()/onScaleChanged, multiply the factor intofitWindowandresizeWindow, record the zoomfitWindowapplies so it can be divided back out ofdevicePixelRatio.src-tauri/src/lib.rs— drop the fictional flag; only setWEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTSwhen there are real args.Notes for reviewers
resizelistener fires. No new event wiring needed.Closes #339