1633806 - Basic alert box incorrectly sized for 2nd monitor scaling

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[Hal Wine [:hwine] use NI!]

Attachment: image.png

See attached screen shot -- my display setup is "unusual", but this issue can become a UX problem (see bug 1632899 for a more extreme example).

My machine is a MS Surface 2017, with an external monitor as the main display. This dialog is opened from a Firefox window on the laptop's screen (secondary monitor).

MS sets the default scale for the laptop screen to be 200%. The external monitor's scale is 100%.

100% reproducible - let me know what other information would help.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I wonder if the patch in bug 1609446 would fix this.

Comment 2

[:Gijs (he/him)]

I would actually hope bug 1620575 would already fix this. The screenshots are from release/beta - does the same issue happen with current nightly?

Comment 3

[Hal Wine [:hwine] use NI!]

fwiw, this will be a while -- my nightly is currently pinned while I get data for bug 1628385

Comment 4

[Daniel Bodea [:danibodea]]

This bug received the "regressionwindow-wanted" tag, which means that it is required to find the exact "window of builds" where this issue reproduces and where it doesn't, but firstly, I do not have a MS Surface while working from home. I could try to do it on my desktop with 2 monitors, but I am lacking some more detailed steps to reproduce. I need some exact steps that I could take to reproduce the issue consistently. Can you help?

Alternatively, you could try to perform the testing procedure to find it's regressor, using mozregression:
https://mozilla.github.io/mozregression/

Thank you for your contribution!

Comment 5

[Hal Wine [:hwine] use NI!]

(In reply to :Gijs (he/him) from comment #2)

I would actually hope bug 1620575 would already fix this. The screenshots are from release/beta - does the same issue happen with current nightly?

Sadly, no -- bug still present in Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 ID:20200515093304

MozRegression (with an empty profile) says:

2020-05-15T17:28:36: INFO : Narrowed integration regression window from [1ba5465d, 0690f68a] (3 builds) to [7828a10a, 0690f68a] (2 builds) (~1 steps left)
2020-05-15T17:28:36: DEBUG : Starting merge handling...
2020-05-15T17:28:36: DEBUG : Using url: https://hg.mozilla.org/mozilla-central/json-pushes?changeset=0690f68a8d9984d2653792e3294bf876eecef651&full=1
2020-05-15T17:28:36: DEBUG : Found commit message:
Backed out changeset 7295ca89e880 (bug 1608280) for causing bug 1608912 and bug 1608871 a=backout

2020-05-15T17:28:36: DEBUG : Did not find a branch, checking all integration branches
2020-05-15T17:28:36: INFO : The bisection is done.
2020-05-15T17:28:36: INFO : Stopped

Comment 6

[Hal Wine [:hwine] use NI!]

(In reply to Bodea Daniel [:danibodea] from comment #4)

This bug received the "regressionwindow-wanted" tag, which means that it is required to find the exact "window of builds" where this issue reproduces and where it doesn't, but firstly, I do not have a MS Surface while working from home. I could try to do it on my desktop with 2 monitors, but I am lacking some more detailed steps to reproduce. I need some exact steps that I could take to reproduce the issue consistently. Can you help?

See moz regression info in comment 5

Clearer description of my setup:

• monitor 1 (MS Surface 2017) - scale: 200%; resolution 2736x1824 (both are as recommended by Win10)
• monitor 2 (samsung external) - scale: 100%; resolution 1920x1080 (both are as recommended by Win10)
• Monitor 2 is configured as the main display
• Monitor 2 is logically above Monitor 1

Steps I took during each moz-regression run:

• Window opens on main display (monitor 2)
• drag window to monitor 1 so that none of the window remains showing on monitor 2
• go to any site (I clicked one of the Pocket offerings)
• drag the URL icon from the awesome bar over the "home" icon and drop it
• the "do you want to make this your homepage" alert pops up, which either shows, or doesn't show, the issue

Comment 7

[:Gijs (he/him)]

(In reply to Hal Wine [:hwine] (use NI, please) from comment #5)

(In reply to :Gijs (he/him) from comment #2)

I would actually hope bug 1620575 would already fix this. The screenshots are from release/beta - does the same issue happen with current nightly?

Sadly, no -- bug still present in Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 ID:20200515093304

MozRegression (with an empty profile) says:

2020-05-15T17:28:36: INFO : Narrowed integration regression window from [1ba5465d, 0690f68a] (3 builds) to [7828a10a, 0690f68a] (2 builds) (~1 steps left)
2020-05-15T17:28:36: DEBUG : Starting merge handling...
2020-05-15T17:28:36: DEBUG : Using url: https://hg.mozilla.org/mozilla-central/json-pushes?changeset=0690f68a8d9984d2653792e3294bf876eecef651&full=1
2020-05-15T17:28:36: DEBUG : Found commit message:
Backed out changeset 7295ca89e880 (bug 1608280) for causing bug 1608912 and bug 1608871 a=backout

2020-05-15T17:28:36: DEBUG : Did not find a branch, checking all integration branches
2020-05-15T17:28:36: INFO : The bisection is done.
2020-05-15T17:28:36: INFO : Stopped

Hm, so the final range is https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ba5465db9d10e8b59e736f34f098f0da6d92c33&tochange=0690f68a8d9984d2653792e3294bf876eecef651 , and the first patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1588791 looks like it might have something to do with screen information (like dpi) and how it gets passed for dialogs. Emilio, can you take a look if you think that's a plausible regressor and/or if you see anything else in that pushlog that looks like it could be involved?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Not really. Dialogs are parent process only, and that patch only affects remote browsers... I don't see anything more suspicious there though...

Comment 9

[Daniel Bodea [:danibodea]]

Attachment: alerts displayed incorrectly on a differently scaled display.png

I have also attempted to find a regressor for this issue and these are my results:

2020-06-10T20:32:11.385000: DEBUG : Found commit message:
Bug 1605724 - Call sizeToContent() again when the icon loads if it hasn't loaded yet. r=dao

https://hg.mozilla.org/mozilla-central/rev/234701139a2a61d1262e609c9d8ac42384ecafda

Removed the following CSS rule:

  #iconContainer {
    -moz-box-pack: center;
    min-height: 55px; /* maximum icon height + icon margin */
    min-width: 58px; /* maximum icon width + icon margin */
  }
 
Which enforced the size of the icon row.

The icon loads asynchronously, so by the first time we fire DOMContentLoaded it
may not have loaded yet. This means that sizeToContent() will size the window to
an smaller size and stuff will wrap around when it loads.

<image> doesn't block onload so even delaying this wouldn't work.

Instead, call sizeToContent() again when it loads so that we size the window
right again.

Alternatively / on top of this, we could add a wrapper around the <image>
again and fix its width, may be better too...

Differential Revision: https://phabricator.services.mozilla.com/D58704

2020-06-10T20:32:11.386000: DEBUG : Did not find a branch, checking all integration branches
2020-06-10T20:32:11.391000: INFO : The bisection is done.
2020-06-10T20:32:11.395000: INFO : Stopped

The system setup:

• primary monitor: 2560x1080 and 100% scaling
• secondary monitor: 1440x900 at 150% scaling

Steps used:

1. open browser (window opens on primary monitor.
2. move the window to the secondary monitor
3. open wikipedia.org
4. drag the lock icon from the left of the url address to the "Home" icon.
5. The dialog to set the homepage with the displayed link is displayed.
   Actual: The dialog window is improperly sized.
   Expected: The dialog window is correctly sized.

Comment 10

[Daniel Bodea [:danibodea]]

There is also another unwanted behavior when dragging the window from the primary display to the secondary (differently scaled) one. The window is somewhat dropped (left behind a few pixels) when crossing from one monitor to the other. I will be leaving my NI here so that I can log this extra issue if it's not fixed with the issue.

Comment 11

[Daniel Bodea [:danibodea]]

Removing NI.