musescore / musescore/MuseScore

Changes to screen size are not correctly handled when window is maximized

Open
#28,971 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

UX/interaction
Dominant language
C++
Stars
15.1k
Forks
3.3k
Avg merge
2d 2h
Merged PRs (30d)
91

Description

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce
  1. Open MuseScore
  2. Maximize the main window
  3. Change screen size, either:
    a. by switching between tablet and desktop mode (plug/unpèlug a keyboard) or
    b. by changing screen resolution or
    c. by changing screen orientation (potrait/landscape modes).

Expected behavior: the window adapts to the new screen resolution and controls work as expected
Observed behavior: window is not correctly resized. There is some gap between the window top bar and top of the screen. Controls "clickable" area is shifted wrt the area of the screen they are painted to, ie: some notes are playd back yìif you click on their left or above them, not ON them. Same applies to everything else, I managed to undo an action when trying to restore window size.

Restoring the window (de-maximizing) fixes the issue.

Supporting files, videos and screenshots

Resolution change_.zip

What is the latest version of MuseScore Studio where this issue is present?

OS: Windows 11 Version 24H2 or later, Arch.: x86_64, MuseScore Studio version (64-bit): 4.6.0-252080330, revision: github-musescore-musescore-e7bd8a9

Regression

I was unable to check

Operating system

Windows 11 on ARM

Additional context

I observed this on a Windows 11 ARM device, but it doesn't look like it's ARM-related.

Also, I used the WIndows built-in capturing tool, and you can notice from the video that after changing the screen resolution, it appears as Windows has created a new screen, on top of the old one, which is still visible in the capture underneath the resized one.

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.

Research direction

First reproduce the behavior on Windows 11 using the attached “Resolution change_.zip” while maximizing MuseScore, then compare tablet/desktop mode, resolution, and orientation changes. Done means the maximized window aligns with the screen after each change and controls remain clickable at the locations where they are painted.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.