musescore / musescore/MuseScore

Windows Snap fails when MuseScore is maximised — stays full screen and loses title bar controls

Open
#33,425 0 comments 0 reactions 1 assignee View on GitHub

@Eism is already working on this.

Since May 15, 2026.

os: windows P2 regression MS4 UI
Dominant language
C++
Stars
15.1k
Forks
3.3k
Avg merge
2d 2h
Merged PRs (30d)
91

Description

Issue type

UI bug (incorrect info or interface appearance)

Description with steps to reproduce
  1. Open MuseScore and maximise the window (full screen)
  2. Drag a different window to the top of the screen and select a 50/50 snap layout
  3. The dragged window is placed correctly in its half — observe what happens to MuseScore

Expected: MuseScore resizes to fill the remaining half of the screen and its close/min/max etc icons remain top right window corner.
Actual: MuseScore stays full screen and its close/minimise/maximise etc icons disappear from the title bar

Additional diagnostic clue: If you repeat step 2 immediately after encountering the bug, MuseScore snaps correctly the second time and the title bar controls reappear.

Supporting files, videos and screenshots

https://github.com/user-attachments/assets/49f1962e-5ac5-4daa-a9cf-a7c546bb5ccc

In which versions of MuseScore Studio is this issue present?

4.6.5 (also in my local dev env with MuseScore Studio 5.0.0, built from master at commit 3c30b9676a (upstream PR #33338, merged 2026-05-08)

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

Windows 11

Additional context

Probable root cause
The bug might be in WM_GETMINMAXINFO handling in the muse submodule:
File: framework/ui/internal/platform/windows/winwindowscontroller.cpp
Function: calculateWindowSize()

Probably introduced by: 4ad218709 — "added manually registering the windows in windows controller" (5 Aug 2025)


minMaxInfo->ptMaxSize.x     = monitorWorkAreaRect.right - monitorWorkAreaRect.left;
minMaxInfo->ptMaxSize.y     = monitorWorkAreaRect.bottom - monitorWorkAreaRect.top;
minMaxInfo->ptMaxPosition.x = std::abs(windowRect.left - monitorRect.left);
minMaxInfo->ptMaxPosition.y = std::abs(windowRect.top - monitorRect.top);
minMaxInfo->ptMinTrackSize.x = minMaxInfo->ptMaxSize.x;  // ← bug
minMaxInfo->ptMinTrackSize.y = minMaxInfo->ptMaxSize.y;  // ← bug

ptMinTrackSize declares the minimum size Windows is allowed to resize the window to. Setting it equal to ptMaxSize (the full monitor work area) tells Windows "this window cannot be smaller than the entire screen."

When the snap layout is chosen, Windows first sends SC_RESTORE to un-maximise MuseScore (this succeeds — the window is no longer SW_SHOWMAXIMIZED), then attempts to resize it to half the screen. The ptMinTrackSize constraint blocks that resize, so the window is left in an inconsistent state: SW_SHOWNORMAL internally but still at full-screen dimensions. Qt sees a borderless (WS_POPUP) window covering the entire monitor in a normal (non-maximised) state and flags it as Qt::WindowFullScreen. The QML title bar binding visible: windowVisibility !== Window.FullScreen then hides the controls.

Why the second attempt works: after the failed snap, MuseScore is in SW_SHOWNORMAL state. On the next attempt isWindowMaximized() returns false, calculateWindowSize() exits early, ptMinTrackSize is never set, and Windows can freely resize the window. Both symptoms clear.
Note: ptMaxSize and ptMaxPosition are correct and should be kept — they prevent the maximised window from overlapping the taskbar.

Fix
Remove the two ptMinTrackSize lines:

minMaxInfo->ptMaxSize.x     = monitorWorkAreaRect.right - monitorWorkAreaRect.left;
minMaxInfo->ptMaxSize.y     = monitorWorkAreaRect.bottom - monitorWorkAreaRect.top;
minMaxInfo->ptMaxPosition.x = std::abs(windowRect.left - monitorRect.left);
minMaxInfo->ptMaxPosition.y = std::abs(windowRect.top - monitorRect.top);
// ptMinTrackSize intentionally not set — constraining it to ptMaxSize
// prevents Windows Snap from resizing the window to any sub-monitor zone.

I have tested this fix: with the two lines removed, selecting a 50/50 snap layout while MuseScore is maximised correctly resizes it to half the screen with title bar controls fully intact. I have NOT done any regression testing to find any unwanted downstream effects.

Related issues
This is a new variant of a recurring class of bugs where MuseScore incorrectly enters Window.FullScreen state in various window management scenarios:

#21344 — Maximising on a secondary monitor starts fullscreen instead (different trigger, same symptom)
#16794 — Title bar controls disappear when taskbar is set to auto-hide
#25823 — Window doesn't resize correctly when tiling (different scenario — MuseScore not maximised, layout corruption rather than snap blocking)

Checklist
  • This report follows the guidelines for reporting bugs and issues
  • I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
  • I have attached all requested files and information to this report
  • I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.