1403153 - ~8px top margin on maximized Firefox windows after Windows 10 update (on most resolutions)

Status: RESOLVED WORKSFORME

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

Description

[Johann Hofmann [:johannh]]

[Tracking Requested - why for this release]:
(Not a Firefox regression) Very noticeable visual regression on Windows 10.

See screenshot.

Till noticed that he suddenly had a visible ~8px margin on top of his maximized Firefox window in Windows 10 and attributed it to a Nightly regression. It turns out that this is also reproducible in release and that it only appeared in my local VM (which had not been updated for a while) after fully updating Windows to the latest version.

This is _very_ noticeable in light and dark theme, luckily it's a little less noticeable on default theme (it has the same color as the window background).

Several of us in the Berlin office have been able to reproduce this, but note that this is only happening on certain resolutions (e.g. 1920x1200 and 1366x768, which are quite popular).

Judging by the fact that Till has a very new and up to date Windows machine, the update at fault can not have been deployed more than a couple of weeks ago.

Comment 1

[Johann Hofmann [:johannh]]

Attachment: Screen Shot 2017-09-26 at 15.07.07.png

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

It is suggested that this happened after a change in a Windows API.

Comment 3

[:Gijs (he/him)]

(In reply to Johann Hofmann [:johannh] from comment #0)
> This is _very_ noticeable in light and dark theme, luckily it's a little
> less noticeable on default theme (it has the same color as the window
> background).

Uh, does it, on 56? Does this bug only happen if we're painting the windows background colour instead of the pre-photon grey or the post-photon aubergine?

Comment 4

[:Gijs (he/him)]

Other questions:

1) does this happen with infra builds as well, not just with self-builds?
2) is this on Windows 10 release rather than "insider" builds or other pre-release channels?

It seems highly surprising windows would have made API changes in a Windows update that we wouldn't have caught until after release. :-(

Comment 5

[Johann Hofmann [:johannh]]

(In reply to :Gijs from comment #3)
> (In reply to Johann Hofmann [:johannh] from comment #0)
> > This is _very_ noticeable in light and dark theme, luckily it's a little
> > less noticeable on default theme (it has the same color as the window
> > background).
> 
> Uh, does it, on 56? Does this bug only happen if we're painting the windows
> background colour instead of the pre-photon grey or the post-photon
> aubergine?

Well, the extra space is still present in the default style, but it has the correct color. It's easy to see the difference (for me) by changing resolutions/DPI and comparing the space above tabs.

I'm not sure how DPI plays into this, but there's certainly a difference when changing it (the margin seems larger on low scale). Maybe it's just that the margin is still present but doesn't scale like other items.

Comment 6

[Johann Hofmann [:johannh]]

(In reply to :Gijs from comment #4)
> Other questions:
> 
> 1) does this happen with infra builds as well, not just with self-builds?

Yes, it happens on stable 55 downloaded from our downloads page, if that's what you mean with infra-builds :)

> 2) is this on Windows 10 release rather than "insider" builds or other
> pre-release channels?

I think this is just normal release.

> 
> It seems highly surprising windows would have made API changes in a Windows
> update that we wouldn't have caught until after release. :-(

I'm also surprised mozscreenshots is not catching this, but why might have the "wrong" resolution/DPI combination there.

Comment 7

[Till Schneidereit [:till]]

(In reply to Johann Hofmann [:johannh] from comment #6)
> > 2) is this on Windows 10 release rather than "insider" builds or other
> > pre-release channels?
> 
> I think this is just normal release.

Correct, this is a normal win10 with all current patches applied.

Comment 8

[Oana Botisan, Desktop QA]

I tried to reproduce this bug using both Nightly from 2017-09-23 and latest Nightly on Windows 10x64, but I couldn't. I tried on three different machines and with almost all the resolutions available, including those mentioned in comment 0. 

I even tried to change the resolution in browser changing prefs from about:config but nothing different happened. The top margin remained in the normal parameters. 

Is there something that I missed or maybe didn't do right?

Comment 9

[Johann Hofmann [:johannh]]

(In reply to Oana Botisan from comment #8)
> I tried to reproduce this bug using both Nightly from 2017-09-23 and latest
> Nightly on Windows 10x64, but I couldn't. I tried on three different
> machines and with almost all the resolutions available, including those
> mentioned in comment 0. 
> 
> I even tried to change the resolution in browser changing prefs from
> about:config but nothing different happened. The top margin remained in the
> normal parameters. 
> 
> Is there something that I missed or maybe didn't do right?

Did you change the DPI (text density) settings?

Comment 10

[:Gijs (he/him)]

(In reply to Oana Botisan from comment #8)
> I even tried to change the resolution in browser changing prefs from
> about:config but nothing different happened. The top margin remained in the
> normal parameters. 

Not sure if the about:config stuff is relevant, but if trying to reproduce this I would imagine the version of Windows 10 and the screen resolution and text scaling/DPI (per comment #0, comment #9) as configured through Windows are potential factors that you could try changing in order to find STR.

Comment 11

[Oana Botisan, Desktop QA]

 
> Not sure if the about:config stuff is relevant, but if trying to reproduce
> this I would imagine the version of Windows 10 and the screen resolution and
> text scaling/DPI (per comment #0, comment #9) as configured through Windows
> are potential factors that you could try changing in order to find STR.

I tried to change the text scaling/dpi, the result didn't change. The top margin didn't become bigger. 
And just to be sure, I retested everything on another two machines, even on a laptop and a computer with 4K monitor display. But I couldn't reproduce the bug.

Comment 12

[Johann Hofmann [:johannh]]

(In reply to Oana Botisan from comment #11)
>  
> > Not sure if the about:config stuff is relevant, but if trying to reproduce
> > this I would imagine the version of Windows 10 and the screen resolution and
> > text scaling/DPI (per comment #0, comment #9) as configured through Windows
> > are potential factors that you could try changing in order to find STR.
> 
> I tried to change the text scaling/dpi, the result didn't change. The top
> margin didn't become bigger. 
> And just to be sure, I retested everything on another two machines, even on
> a laptop and a computer with 4K monitor display. But I couldn't reproduce
> the bug.

Are you running the latest Windows?

Comment 13

[Oana Botisan, Desktop QA]

Yes, all the computers I tested on have the latest Windows (version 1703). I checked and all it says is that the device is up to date.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

If this isn't widespread or easily reproducible, and it isn't a new regression, we are not likely to fix it for 56.  Sounds like we still need to get reliable STR, here.

Comment 15

[Till Schneidereit [:till]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #14)
> If this isn't widespread or easily reproducible, and it isn't a new
> regression, we are not likely to fix it for 56.  Sounds like we still need
> to get reliable STR, here.

Note that it was reproduced by at least three different people on different machines with different configurations. I can only see one or potentially two common factors: all machines were in the Berlin office, and at least two were (different) Dell laptops.

Quite unexpectedly, it seems like the location might make a difference: I'm in Chicago right now and just tested: I can't reproduce the issue with an otherwise unchanged setup.

Comment 16

[(No longer employed by Mozilla) Aaron Klotz]

To me it is easily reproducible, but only if I boot up with a high-dpi display, then plug in a lower-dpi display, and then Firefox over to the lower dpi window.

Comment 17

[Johann Hofmann [:johannh]]

(In reply to Till Schneidereit [:till] from comment #15)
> (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #14)
> > If this isn't widespread or easily reproducible, and it isn't a new
> > regression, we are not likely to fix it for 56.  Sounds like we still need
> > to get reliable STR, here.
> 
> Note that it was reproduced by at least three different people on different
> machines with different configurations. I can only see one or potentially
> two common factors: all machines were in the Berlin office, and at least two
> were (different) Dell laptops.
> 
> Quite unexpectedly, it seems like the location might make a difference: I'm
> in Chicago right now and just tested: I can't reproduce the issue with an
> otherwise unchanged setup.

But do you have your a big screen with the same resolution over there or just your laptop?

I can reproduce this without attaching to another display, but only on certain resolutions. FWIW, I _can't_ reproduce this on the Quantum reference machine on default settings.

I agree that this seems heavily dependent on screen resolution/DPI and it doesn't seem to be as widespread as I feared. We might need to drop the tracking flags, but we should definitely keep an eye on this.

Comment 18

[Dave Townsend [:mossop]]

I see this but only on my external monitor which is using a scaling factor of 125%. My internal monitor uses a scaling factor of 200%.

Comment 19

[Dave Townsend [:mossop]]

The browser toolbox reports that the <vbox id="titlebar"> has a 10.4px padding-top computed. I can't see any styles defining this though.

Comment 20

[Dão Gottwald [:dao]]

(In reply to Dave Townsend [:mossop] from comment #19)
> The browser toolbox reports that the <vbox id="titlebar"> has a 10.4px
> padding-top computed. I can't see any styles defining this though.

It's from -moz-appearance: -moz-window-titlebar-maximized.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

I've been seeing something like this since installing the Fall Creators Update RTM build (I'm on the release preview ring - should be going to GA in the next week or so).

Comment 22

[Ryan VanderMeulen [:RyanVM]]

[Tracking Requested - why for this release]: The Win10 Fall Creators Update went to GA today. I'm afraid we're going to start getting more reports of this issues as users start updating to it.

Comment 23

[Julien Cristau [:jcristau]]

It sounds like this shouldn't be marked as a regression, if it started with a windows update.

Comment 24

[:Gijs (he/him)]

(In reply to Dão Gottwald [::dao] from comment #20)
> (In reply to Dave Townsend [:mossop] from comment #19)
> > The browser toolbox reports that the <vbox id="titlebar"> has a 10.4px
> > padding-top computed. I can't see any styles defining this though.
> 
> It's from -moz-appearance: -moz-window-titlebar-maximized.

Given this and bug 1398395, could we workaround this class of bugs by not setting this moz-appearance style for the win10 case? AIUI we use custom titlebar buttons and colours anyway... Would we miss out on any functionality by removing this style that I'm not aware of?

Comment 25

[Dão Gottwald [:dao]]

Might be worth a try.

Comment 27

[Ryan VanderMeulen [:RyanVM]]

We may want to revisit this now that the April 2018 is being rolled out to the public. I'm worried this is going to start gathering dupes.