1687774 - Hamburger menu opens slightly larger and then shrinks to proper size when the firefox window is on the edge of MPB laptop screen and secondary display

Status: RESOLVED DUPLICATE of bug 1701070

(Toolkit :: UI Widgets, defect)

Description

[Brian Grinstead [:bgrins]]

Attachment: hamburger-on-edge-of-second-screen.gif

STR:

Set up second monitor to the aligned to the right of the macbook screen
Drag Firefox as rightmost as you can in the laptop window
Open the hamburger menu

Expected:
Hamburger menu opens at the proper size

Actual:
Hamburger menu opens a bit too large at first and then snaps to the right size

Comment 1

[Brian Grinstead [:bgrins]]

Attachment: hamburger-on-edge-of-screen-repro.gif

This is what the configuration looks like physically

Comment 2

[Brian Grinstead [:bgrins]]

Attachment: display-information.png

Comment 3

[Haik Aftandilian [:haik]]

I expect the fix for bug 1689682 to address this too.

Comment 4

[Haik Aftandilian [:haik]]

@bgrins, could you verify that you can no longer reproduce this with Nightly now that bug 1689682 has landed?

Comment 5

[Haik Aftandilian [:haik]]

Bug 1689682 is being backed out due to a Windows regression so no need to verify this.

Comment 6

[Haik Aftandilian [:haik]]

This ended up being fixed in bug 1701070 which is now on Nightly.

This problem was caused by nsCocoaWindow::Create() interpreting its aRect argument as an absolute position instead of a position relative to its parent window. As a result, after nsCocoaWindow::Create() runs, the hamburger menu's NSWindow's position is likely to be on the screen that has origin (0,0) which may not be the correct screen. This happens before the window is shown, but results in the window having an incorrect scaling factor. The window is moved to the correct top-left position before it is shown, but the incorrect scaling factor results in the window briefly being displayed twice as large.

In the example I could reproduce, my screen configuration[1] was as follows.

$ macos-screeninfo.py 
      (main) Screen0: scale:1 at origin (     0,      0) with size  3840 by  2160
             Screen1: scale:2 at origin ( -1024,   1619) with size  1024 by   640

The main window is on screen1 to the left of the main screen screen0. When clicking on the hamburger menu, the popup widget is created and the nsCocoaWindow::Create() bug puts the window initially on screen0 with scale factor of 1.

Before the window is shown with the Show() method, it is moved to the correct location via nsBaseWidget::MoveClient() which converts from layout device coordinates to desktop coordinates using the widget’s current scale factor of 1. Since the correct scale for the new window position is 2, this makes the window be drawn twice as large (although at the correct top-left position).

The setFrameTopLeftPoint call in nsCocoaWindow::Move() triggers the. NSWindow backingScaleFactor to be changed which causes nsCocoaWindow::BackingScaleFactorChanged() to be called which corrects the size of the window, snapping it to the correct size and scale.

The problem does not occur on the very first time the hamburger window is opened because for that instance the window is created with a zero width and height resulting in the scaling factor for the NSWindow to be 2 (which is an NSWindow quirk.)

1. macos-screeninfo.py