8000 Window relaunches in a tiny window after being closed while maximized (maximize state not persisted) · Issue #57 · amirlehmam/wmux · GitHub
[go: up one dir, main page]

Skip to content

Window relaunches in a tiny window after being closed while maximized (maximize state not persisted) #57

Closed

Description

@kevmtt

Bug Report

Expected Behaviour

When wmux is closed while maximized (full-size) on a monitor, relaunching the executable should restore it to that same maximized state on the same monitor.

What Happened

After closing wmux while it was running maximized on my 32″ external monitor, relaunching the .exe brings it back in a very small window — not maximized, and noticeably smaller than any normal default window. I then have to manually maximize it again every time.

Additional Information

Setup

  • Laptop: 14″ 3K OLED, 2880 × 1800, 16:10, Windows default scaling ~200%.
  • External monitor: 32″ screen, used as the primary work display. wmux runs maximized here.
  • Multi-monitor: laptop panel + 32″ external, with very different DPI / scale factors between the two.
  • wmux version: 0.10.0
  • OS: Windows 11

Technical findings (from the source)
The window-bounds persistence path saves the window rectangle but not the maximized flag, and never re-maximizes on restore:

  • src/main/index.ts:255-260 — on session:save, only win.getBounds() is stored; win.isMaximized() is never recorded.
  • src/main/index.ts:270-273 → src/main/window-manager.ts:26-67 — createWindow(savedBounds) rebuilds the window from raw width/height/x/y and never calls win.maximize().
  • src/main/window-manager.ts:50-51 — minWidth: 800, minHeight: 500 is the floor a mis-scaled restore can collapse to.
  • src/main/window-manager.ts:29-42 — saved-bounds validation only checks screen intersection; no maximize restore, fallback is just 1400×900.

Because Electron bounds are device-independent pixels relative to a specific display, bounds captured on the low-DPI 32″ monitor and re-applied before the window is placed on that monitor (while the high-DPI Zenbook panel is primary) can shrink the window toward the min-size floor — which matches the "very small" result.

Reproduce

  1. Run wmux on a multi-monitor setup where the monitors have different DPI/scaling (e.g. high-DPI laptop panel + lower-DPI 32″ external).
  2. Move wmux to the 32″ external monitor and maximize it (full-size).
  3. Close wmux completely.
  4. Launch the wmux executable again.
  5. Observe: wmux opens in a very small window instead of restoring the maximized state on the 32″ monitor.

Summary — proposed changes / likely cause

The maximize state is not part of the persisted session, and on multi-monitor + mixed-DPI setups the saved DIP bounds get re-applied on the wrong display, collapsing the window toward its min size.

Proposed fixes (in src/main/):

  1. Persist the maximized flag. In the session:save handler (index.ts:255-260) also store win.isMaximized(), and save win.getNormalBounds() (not getBounds()) so the pre-maximize rectangle is kept. Add a maximized?: boolean field to SessionData.windows[] in session-persistence.ts.
  2. Re-maximize on restore. In createWindow() (window-manager.ts), after creating the BrowserWindow, call win.maximize() when the saved state was maximized.
  3. Harden multi-monitor restore. Defer applying bounds / maximizing until the target display is resolved (use screen.getDisplayMatching(savedBounds) and clamp into that display's workArea), so mixed-DPI bounds aren't mis-applied to the primary display. Keep the existing off-screen fallback.
  4. Optional: remember which display the window was on and restore there explicitly.

Activity

  1. added a commit that references this issue on Jun 25, 2026
  2. amirlehmam commented on Jun 25, 2026

    @amirlehmam
    Owner

    Fixed in v0.11.0 🎉 — and thank you for the genuinely excellent bug report; your source-level analysis was spot on and is exactly what I implemented.

    Changes (in src/main/):

    1. Persist the maximized flag. session:save now stores win.isMaximized() and saves win.getNormalBounds() (the pre-maximize rectangle) instead of getBounds(). Added a maximized?: boolean field to SessionData.windows[].
    2. Re-maximize on restore. createWindow() calls win.maximize() when the saved state was maximized.
    3. Harden multi-monitor / mixed-DPI restore. Bounds are now matched to a display via screen.getDisplayMatching() and clamped into that display's workArea, so DIP bounds captured on the 32″ monitor can no longer be mis-applied to the high-DPI laptop panel and collapse the window toward the min-size floor.

    This should restore wmux maximized on the same monitor every relaunch. Build: https://github.com/amirlehmam/wmux/releases/tag/v0.11.0 (extract → right-click folder → Properties → Unblock, unsigned). Please reopen if it still misbehaves on your dual-monitor setup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      2BD7
      0