Closed Bug 1832648 Opened 3 years ago Closed 2 years ago

200% DPI scaling on second monitor breaks Firefox window with hardware acceleration enabled

Categories

(Core :: Widget: Win32, defect, P3)

Firefox 113
Desktop
Windows 10
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: governmentslave, Unassigned)

Details

(Keywords: multi-monitors, Whiteboard: [win:multimonitors])

Attachments

(1 file)

Attached image ffbug.png

HARDWARE: Win 10, NVidia 1080 Ti, two 1440p displays (default 100% scaling) & one 2160p display (200% scaling)

SCALING BUG HISTORY: I switched to FF about a year ago and had some issues with scaling then. Slightly different issue (FF simply ignored Windows scaling), and that issue was solved by setting the High DPI Scaling Override in the FF shortcut itself to the System (Enhanced) option.

NEW BUG: This recent update has caused my scaling to be broken in a new way. In the image provided, this is what an FF window looks like on a 4k display at 200% Windows scaling. Notice the buttons (and all elements) are in the right spot according to my mouse, but there is no scaling.

TEMP FIX: I tried changing DPI scaling settings in the FF shortcut like before, but nothing worked. The only fix I have found for this is to disable hardware acceleration. If I enable it, my FF window scales like this. If I disable it, it scales perfectly fine.

TO REPRODUCE: Presumably use a multimonitor setup, with a display set to above 100% display scaling in Windows 10, and drag a FF window onto it. I don't have multiple setups to test reproduction.

I would really like to continue using hardware acceleration and have Firefox scale properly on each display. I have never had any scaling issues on any application at all except Firefox (used both Chrome and Edge on this exact setup for years).

Component: General → Widget: Win32
Keywords: multi-monitors
Product: Firefox → Core

TO REPRODUCE: Presumably use a multimonitor setup, with a display set to above 100% display scaling in Windows 10, and drag a FF window onto it. I don't have multiple setups to test reproduction.

Alas, I can confirm that's not sufficient; I use a 2-monitor setup, one of which is at 175%.

Since this is a recent behavior change, do you think you could use mozregression to narrow down when this started occurring? (Simply answer "good" or "bad" based on whether or not a build reproduces the bug. Once finished, please post the output from the last run. It should give a last good and first bad revision as well as a link to look at the changesets in that range. Thank you!)

Severity: -- → S3
Flags: needinfo?(governmentslave)
Priority: -- → P3
Whiteboard: [win:multimonitors]

I can't manage to reproduce this issue either, but I don't possess HDPI monitors (considering these might be a requirement).
I wonder if this issue occurs on a newly created profile or if it might be caused by some unexpected user data...?
Could you have some time to confirm that and hopefully also Ray Kraesig's request in comment 1?
(https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles)

Thank you for your contribution!

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED, closing the bug as incomplete.

For more information, please visit BugBot documentation.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(governmentslave)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: