Open Bug 1827159 Opened 2 years ago Updated 2 years ago

Sizes of Firefox's windows get unexpectedly small after trying switching accounts of Windows

Categories

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

Firefox 111
defect

Tracking

()

People

(Reporter: ozawa.tsuyoshi, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Steps to reproduce:

Firefox version 111.0.1 (64-bit), Windows 10

How to reproduce:

  1. Launching Firefox (open a window or multiple windows) as a user.
  2. Trying to switch from a user account to another user [*].
  3. Logging in as the user launched the a Firefox window or Firefox windows in the procedure 1.

[*] Microsoft, How to switch users (accounts) in Windows, https://support.microsoft.com/en-us/windows/how-to-switch-users-accounts-in-windows-660d4dcd-fa8d-7467-10b3-fee0e70e11d4

Actual results:

The sizes of all Firefox windows get unexpectedly small as a attached screenshot.

Expected results:

The sizes of all Firefox windows should be preserved as seen before trying switching the accounts.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Win32
Product: Firefox → Core

I can repro this, or something very similar. Given User A with non-default DPI settings on the primary monitor and User B:

  1. Open a Firefox window as user A on the primary monitor.
  2. Open the Switch User dialog, as though you were going to switch to User B.
  3. Instead, immediately select and switch to the (still-logged-in) User A.

The Firefox window will not necessarily remain in the same position.

Unfortunately, this seems to be an issue on Windows' end. Based on preliminary testing, the "Switch User" screen is shown in the default DPI for the primary monitor, and Windows changes the monitor DPI for User A when showing it; this causes all open windows to be moved and resized, and restoring the DPI doesn't generally restore their positions. A RegEdit window I had open while doing the testing suffered this as well. (I suspect switching to User B may potentially cause yet another DPI-change notification and repositioning of windows in User A's session, but I haven't specifically tested that.)

We could theoretically hack around this and ensure that a sequence of DPI transitions that started and ended at the same value left all Firefox windows in the same place. Unfortunately, "hack" is probably the right word for that.

Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

Thanks a lot for the reproduction, Ray. As you indicated, I run Firefox with non-default DPI settings.

Unfortunately, "hack" is probably the right word for that.

An interesting behavior is that all other windows except Firefox launched at the time seem to recover their window size after logging in. I don't know if all of them do such kinds of hacks. Anyway, thanks for your confirmation.

An interesting behavior is that all other windows except Firefox launched at the time seem to recover their window size after logging in.

I should clarify, then, that this is not what my testing showed. I have seen both RegEdit (as noted in comment #2) and CMD.EXE experience this, though neither consistently. (But then, I have also not had it occur consistently with Firefox.)

On the other hand, I have also seen it suspiciously fail to occur with a Notepad window that was deliberately positioned to try to trigger it; and so far, my audio player (Audacious) appears to have been completely unaffected despite remaining open through all testing.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: