#71 Dispatch a resize event on the Windows/WebView2 zoom path

[Anonymous]

Originally created by: kristofferR

Split out from the [#48] review (PR [#70]).

Problem

inject/src/messenger/features/zoom.ts applies zoom two ways:

• Non-Windows: sets document.documentElement.style.zoom and dispatches a resize event.
• Windows/WebView2: applies a CSS transform: scale(...) (WebView2 ignores zoom) but does not dispatch resize.

Several page features reschedule layout work off resize — notably hide-names and login-tidy. On Windows, a zoom change can therefore leave those recalculations stale until the next real resize.

Why it's a separate issue

This is pre-existing behavior, transcribed verbatim from the original single-file messenger.js in PR [#70] (a no-behavior-change refactor). CodeRabbit flagged it and agreed it was reasonable to defer:

• It's Windows/WebView2-specific and can't be smoke-tested from macOS.
• A CSS transform doesn't alter the layout viewport the way zoom does, so whether resize is even the right signal (vs. a dedicated relayout nudge) deserves a deliberate decision + Windows testing.

Fix sketch

After the Windows transform branch in applyZoom, dispatch window.dispatchEvent(new Event("resize")) to match the non-Windows path — or introduce a Carrier-specific relayout signal the affected features listen for. Validate on an actual Windows build that hide-names/login-tidy recompute and that it doesn't cause a layout loop with the transform.

Ref [#48]

[Anonymous]

Ticket changed by: kristofferR

• status: open --> closed

[Anonymous]

Originally posted by: kristofferR

Fixed in [#140]. The Windows/WebView2 zoom path now relayouts correctly (it dispatches the resize the WebView needs after a zoom change).