1249496 - Tabs in the titlebar (or menu titles, if the menubar is visible) are cut off at the top in maximized windows on mixed DPI systems

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Dave Camp (:dcamp)]

Attachment: Image 2016-02-18 at 6.15.49 PM.png

I'm on windows 10.  High-dpi laptop screen extended to low-dpi monitor.  When connected to the monitor, maximizing on either screen cuts off the top of the tabs.

When not connected to the external screen, it seems to work fine.

Comment 1

[Matthew N. [:MattN]]

Possibly a regression from bug 890156. Testing on a version before that landed or using mozregression would help narrow it down.

It may also be useful to know if the manual calculations are stale because the monitor was attached after the front-end calculated[1] the heights of elements. See if running:
>  TabsInTitlebar.updateAppearance(true)
in the Browser Console[1] helps.

[1] https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-tabsintitlebar.js?rev=29dd8f5e46f8#136
[2] https://developer.mozilla.org/en-US/docs/Tools/Browser_Console

Comment 2

[:Gijs (he/him)]

(In reply to Matthew N. [:MattN] (behind on bugmail) from comment #1)
> Possibly a regression from bug 890156. Testing on a version before that
> landed or using mozregression would help narrow it down.
> 
> It may also be useful to know if the manual calculations are stale because
> the monitor was attached after the front-end calculated[1] the heights of
> elements. See if running:
> >  TabsInTitlebar.updateAppearance(true)
> in the Browser Console[1] helps.
> 
> [1]
> https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-
> tabsintitlebar.js?rev=29dd8f5e46f8#136
> [2] https://developer.mozilla.org/en-US/docs/Tools/Browser_Console

Dave, do you have cycles to test this?

Comment 3

[Dave Camp (:dcamp)]

Yeah, I'll make time.

Comment 4

[Jonathan Kew [:jfkthame]]

Note that the details of the behavior here may have changed slightly as a result of bug 1245442, which just landed. There's still a problem, though; that certainly didn't fix this issue.

Comment 5

[Benjamin Kerensa [:bkerensa]]

Even though we do not have this narrowed down lets go ahead and track this

Comment 6

[Jonathan Kew [:jfkthame]]

Jim, do you know someone who could help look into this? I'm assuming we need to do something with how we handle the WM_NCCALCSIZE message and the window's mCaptionHeight, mNonClientOffset, etc., when there's a discrepancy between the window's DefaultScaleFactor() and the system's SystemScaleFactor().

But I don't really understand how all this is working.... and when I've tried to make adjustments that improve the display, they end up disabling the Windows minimize/maximize/close buttons at the top right (see also bug 1245442). Do we have someone who better understands the Windows APIs involved here?

Comment 7

[Jonathan Kew [:jfkthame]]

(Moving this to Core:Widget, as I think that's where it needs to be fixed.)

Comment 8

[:Gijs (he/him)]

Jonathan, did you try running the stuff in comment #1 to see if that helped at all?

It's not necessarily widget's fault... we do our own magic to position the tabs + menus correctly in chrome code. On Win10, if the titlebar buttons react correctly (ie they don't also get cut off) then it seems like there might be an issue with the chrome code that does the positioning here.

Of course, the chrome code in question relies heavily on measurements it gets from layout using getBoundingClientRect and some other friends / computed style / etc. . Maybe one of those is giving results that are wrong as a result of the DPI change?

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs Kruitbosch from comment #8)
> Jonathan, did you try running the stuff in comment #1 to see if that helped
> at all?

Yes, and it didn't seem to have any effect.

> It's not necessarily widget's fault... we do our own magic to position the
> tabs + menus correctly in chrome code. On Win10, if the titlebar buttons
> react correctly (ie they don't also get cut off) then it seems like there
> might be an issue with the chrome code that does the positioning here.

Fair enough, maybe it was premature to move this. I was thinking I might try to dig into that code a bit further and see if I could understand what it's doing, in case that really is the problem area.... or could you take a look?

> Of course, the chrome code in question relies heavily on measurements it
> gets from layout using getBoundingClientRect and some other friends /
> computed style / etc. . Maybe one of those is giving results that are wrong
> as a result of the DPI change?

Possibly, although if there were problems with that, I'd expect them to show up much more widely.

Comment 10

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> > It's not necessarily widget's fault... we do our own magic to position the
> > tabs + menus correctly in chrome code. On Win10, if the titlebar buttons
> > react correctly (ie they don't also get cut off) then it seems like there
> > might be an issue with the chrome code that does the positioning here.
> 
> Fair enough, maybe it was premature to move this. I was thinking I might try
> to dig into that code a bit further and see if I could understand what it's
> doing, in case that really is the problem area.... or could you take a look?

I don't have a setup that allows me to do that. I have a win10 VM (which obviously can't connect a secondary display) and a surface pro 3 which only has a mini-displayport, which my external screens don't have - so I'd have to go get a converter cable from mini-displayport to HDMI or something like that...

A simple way to see what's going on is using the browser toolbox and seeing whether the negative margin on the #titlebar and the height of the tabstoolbar (if the menubar is hidden) match up. In maximized mode on win10 there should be no padding or margin so they should match 1:1 in terms of CSS pixels.

> > Of course, the chrome code in question relies heavily on measurements it
> > gets from layout using getBoundingClientRect and some other friends /
> > computed style / etc. . Maybe one of those is giving results that are wrong
> > as a result of the DPI change?
> 
> Possibly, although if there were problems with that, I'd expect them to show
> up much more widely.

I mean, there are several options here, not least that maybe we do different things for e10s-based content documents or for XUL or for chrome documents, or that only some of the ways we're reading info (getBoundingClientRect, getComputedStyle, CSSOM elem.style.someProp reading, ...) are busted?

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs Kruitbosch from comment #10)
> A simple way to see what's going on is using the browser toolbox and seeing
> whether the negative margin on the #titlebar and the height of the
> tabstoolbar (if the menubar is hidden) match up. In maximized mode on win10
> there should be no padding or margin so they should match 1:1 in terms of
> CSS pixels.

With the window maximized on an external display (scaling 100%) connected to a hi-dpi laptop (internal main display is at 200%), I'm seeing tabs slightly cut off, and the toolbox shows me:
  #titlebar margin-bottom: -30px
  #TabsToolbar height: 31px

So there's a slight mismatch, but it doesn't seem like enough to account fully for the visual discrepancy. To make it look "right" on the screen, I need to adjust #titlebar.margin-bottom to about -23px.

When I maximize the window on the hi-dpi (primary) screen, it looks OK. The toolbox shows the same TabsToolbar height & titlebar margin-bottom values (with the 1px discrepancy; not sure where that comes from).

Comment 12

[Jonathan Kew [:jfkthame]]

And fwiw, if I make the external (lo-dpi) display the primary monitor, the maximized window looks correct there (but on the hi-dpi screen it has a bit more margin above the tabs than expected -- the opposite problem, though it's less glaring). The toolbox still shows the same values for the titlebar margin and the tabstoolbar height in this setup, too.

Comment 13

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #11)
> (In reply to :Gijs Kruitbosch from comment #10)
> > A simple way to see what's going on is using the browser toolbox and seeing
> > whether the negative margin on the #titlebar and the height of the
> > tabstoolbar (if the menubar is hidden) match up. In maximized mode on win10
> > there should be no padding or margin so they should match 1:1 in terms of
> > CSS pixels.
> 
> With the window maximized on an external display (scaling 100%) connected to
> a hi-dpi laptop (internal main display is at 200%), I'm seeing tabs slightly
> cut off, and the toolbox shows me:
>   #titlebar margin-bottom: -30px
>   #TabsToolbar height: 31px
> 
> So there's a slight mismatch, but it doesn't seem like enough to account
> fully for the visual discrepancy. To make it look "right" on the screen, I
> need to adjust #titlebar.margin-bottom to about -23px.

Hrm, maybe I'm wrong about how the suggested heights of things ought to play out here.

What's the content height of the titlebar ?

> When I maximize the window on the hi-dpi (primary) screen, it looks OK. The
> toolbox shows the same TabsToolbar height & titlebar margin-bottom values
> (with the 1px discrepancy; not sure where that comes from).

The 1px discrepancy sounds like a rounding error of sorts, especially if there are borders in play, I believe those somehow end up clamped by layout, and other things (margins/paddings) are not clamped, so that might explain some of that (though it'd need more investigation to see exactly how that's confusing the algorithm in browser-tabsintitlebar.js ) .

Comment 14

[Jim Mathies [:jimm]]

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> Jim, do you know someone who could help look into this? I'm assuming we need
> to do something with how we handle the WM_NCCALCSIZE message and the
> window's mCaptionHeight, mNonClientOffset, etc., when there's a discrepancy
> between the window's DefaultScaleFactor() and the system's
> SystemScaleFactor().
> 
> But I don't really understand how all this is working.... and when I've
> tried to make adjustments that improve the display, they end up disabling
> the Windows minimize/maximize/close buttons at the top right (see also bug
> 1245442). Do we have someone who better understands the Windows APIs
> involved here?

Myself, although I don't have the hardware to test on multiple displays and win10 at the moment. We're trying to put together a team for this type of work (if in fact this is widgets fault) but this hasn't come together yet. I can put the hardware together to do the testing it would take a week or so to get it together. ni me if you think this would be worth it.

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to Jim Mathies [:jimm] from comment #14)
> (In reply to Jonathan Kew (:jfkthame) from comment #6)
> > Jim, do you know someone who could help look into this? I'm assuming we need
> > to do something with how we handle the WM_NCCALCSIZE message and the
> > window's mCaptionHeight, mNonClientOffset, etc., when there's a discrepancy
> > between the window's DefaultScaleFactor() and the system's
> > SystemScaleFactor().
> > 
> > But I don't really understand how all this is working.... and when I've
> > tried to make adjustments that improve the display, they end up disabling
> > the Windows minimize/maximize/close buttons at the top right (see also bug
> > 1245442). Do we have someone who better understands the Windows APIs
> > involved here?
> 
> Myself, although I don't have the hardware to test on multiple displays and
> win10 at the moment. We're trying to put together a team for this type of
> work (if in fact this is widgets fault) but this hasn't come together yet. I
> can put the hardware together to do the testing it would take a week or so
> to get it together. ni me if you think this would be worth it.

OK, thanks. I'm going to try and look a bit further into the front-end stuff Gijs is talking about, to see if the problem really is there, but if that doesn't lead anywhere then I'll ping you again.

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs Kruitbosch from comment #13)
> (In reply to Jonathan Kew (:jfkthame) from comment #11)
> > (In reply to :Gijs Kruitbosch from comment #10)
> > > A simple way to see what's going on is using the browser toolbox and seeing
> > > whether the negative margin on the #titlebar and the height of the
> > > tabstoolbar (if the menubar is hidden) match up. In maximized mode on win10
> > > there should be no padding or margin so they should match 1:1 in terms of
> > > CSS pixels.
> > 
> > With the window maximized on an external display (scaling 100%) connected to
> > a hi-dpi laptop (internal main display is at 200%), I'm seeing tabs slightly
> > cut off, and the toolbox shows me:
> >   #titlebar margin-bottom: -30px
> >   #TabsToolbar height: 31px
> > 
> > So there's a slight mismatch, but it doesn't seem like enough to account
> > fully for the visual discrepancy. To make it look "right" on the screen, I
> > need to adjust #titlebar.margin-bottom to about -23px.
> 
> Hrm, maybe I'm wrong about how the suggested heights of things ought to play
> out here.
> 
> What's the content height of the titlebar ?

It's content is 21px, and it has a 9px margin-bottom (inline style on #titlebar-content).

The #titlebar-buttonbox-container also has a height of 21px. I wonder if this may be a problem? Because Windows doesn't scale the non-client controls, the minimize/maximize/close buttons are actually much bigger than this on the lo-dpi screen. And if I force the #titlebar-buttonbox-container to have a larger height, the tabs get pushed down accordingly, and no longer cut off.

Not sure yet how that 21px is arrived at...

> 
> The 1px discrepancy sounds like a rounding error of sorts...

Yes, I think that's quite likely -- and probably not important here.

Comment 17

[Matthew N. [:MattN]]

(In reply to Jonathan Kew (:jfkthame) from comment #16)
> The #titlebar-buttonbox-container also has a height of 21px. I wonder if
> this may be a problem? Because Windows doesn't scale the non-client
> controls, the minimize/maximize/close buttons are actually much bigger than
> this on the lo-dpi screen. And if I force the #titlebar-buttonbox-container
> to have a larger height, the tabs get pushed down accordingly, and no longer
> cut off.
> 
> Not sure yet how that 21px is arrived at...

See `-moz-appearance: -moz-window-button-box;` on #titlebar-buttonbox which gets its dimensions from NS_THEME_WINDOW_BUTTON_BOX*, specifically
https://mxr.mozilla.org/mozilla-central/source/widget/windows/nsNativeThemeWin.cpp#2512

Comment 18

[:Gijs (he/him)]

(In reply to Matthew N. [:MattN] (behind on bugmail) from comment #17)
> (In reply to Jonathan Kew (:jfkthame) from comment #16)
> > The #titlebar-buttonbox-container also has a height of 21px. I wonder if
> > this may be a problem? Because Windows doesn't scale the non-client
> > controls, the minimize/maximize/close buttons are actually much bigger than
> > this on the lo-dpi screen. And if I force the #titlebar-buttonbox-container
> > to have a larger height, the tabs get pushed down accordingly, and no longer
> > cut off.
> > 
> > Not sure yet how that 21px is arrived at...
> 
> See `-moz-appearance: -moz-window-button-box;` on #titlebar-buttonbox which
> gets its dimensions from NS_THEME_WINDOW_BUTTON_BOX*, specifically
> https://mxr.mozilla.org/mozilla-central/source/widget/windows/
> nsNativeThemeWin.cpp#2512

The sizing of the titlebar button box that contains the button is actually different on Windows 10, and NOT the result of the widget code. It's done here:

https://dxr.mozilla.org/mozilla-central/rev/4657041c6f77b36b1fb9647c28f53f4f51757360/browser/themes/windows/browser-aero.css#107-126

which sets moz-appearance: none. Note also that we then have a series of hacks for the 25% DPI stops here:

https://dxr.mozilla.org/mozilla-central/rev/4657041c6f77b36b1fb9647c28f53f4f51757360/browser/themes/windows/browser-aero.css#161-205

... but I don't really see why that would be an issue here, as the main screen is 200% and the other 100%, so none of that code should run.

With the CSS from the first link, I'd expect the button box (when maximized) to be sized at 28 CSS px high - 12px for the icon, and two times 8px for the padding on the buttons, and the buttonbox should be sizing to match those buttons. What am I missing?

Something that I'm still not clear about, and I thought I asked before - are the titlebar buttons also cut off? Or are those in the right place and is it just the menubar/tabs ?

Comment 19

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #16)
> (In reply to :Gijs Kruitbosch from comment #13)
> > (In reply to Jonathan Kew (:jfkthame) from comment #11)
> > > (In reply to :Gijs Kruitbosch from comment #10)
> > > > A simple way to see what's going on is using the browser toolbox and seeing
> > > > whether the negative margin on the #titlebar and the height of the
> > > > tabstoolbar (if the menubar is hidden) match up. In maximized mode on win10
> > > > there should be no padding or margin so they should match 1:1 in terms of
> > > > CSS pixels.
> > > 
> > > With the window maximized on an external display (scaling 100%) connected to
> > > a hi-dpi laptop (internal main display is at 200%), I'm seeing tabs slightly
> > > cut off, and the toolbox shows me:
> > >   #titlebar margin-bottom: -30px
> > >   #TabsToolbar height: 31px
> > > 
> > > So there's a slight mismatch, but it doesn't seem like enough to account
> > > fully for the visual discrepancy. To make it look "right" on the screen, I
> > > need to adjust #titlebar.margin-bottom to about -23px.
> > 
> > Hrm, maybe I'm wrong about how the suggested heights of things ought to play
> > out here.
> > 
> > What's the content height of the titlebar ?
> 
> It's content is 21px, and it has a 9px margin-bottom (inline style on
> #titlebar-content).
> 
> The #titlebar-buttonbox-container also has a height of 21px. I wonder if
> this may be a problem? Because Windows doesn't scale the non-client
> controls, the minimize/maximize/close buttons are actually much bigger than
> this on the lo-dpi screen. And if I force the #titlebar-buttonbox-container
> to have a larger height, the tabs get pushed down accordingly, and no longer
> cut off.
> 
> Not sure yet how that 21px is arrived at...

What's also confusing to me is why there is a cut-off at all in any variation of this code, purely because of that height being different from what's expected...

If #titlebar-content has a height of 21px and a margin-bottom of 9px, and then the margin-bottom on the #titlebar is -30px, that should even out, and so the tabs should be aligning with the top of the #titlebar, right?

Checking on my 100% dpi win8 machine with the DOM Inspector add-on (the browser toolbox inspector doesn't seem to have a 'position' part to its box model tab? Note that DOMI works on nightly but it will only start if you have a non-remote browser in the current tab's content area (e.g. about:addons, about:config, ...) because it's not been updated to know about e10s), it seems that the #titlebar itself has a -moz-appearance of -moz-window-titlebar-maximized, which seems to end up meaning the element's top is actually 8px 'above' the top of the window, with a padding-top of 8px so that titlebar-content aligns exactly with the top of the window. It looks like that's the result of the moz-appearance value and widget code in nsNativeThemeWin. This code:

https://dxr.mozilla.org/mozilla-central/rev/4657041c6f77b36b1fb9647c28f53f4f51757360/widget/windows/nsNativeThemeWin.cpp#1664-1668

seems relevant there, and AIUI is what seems to end up with DOM Inspector thinking the titlebar starts 8px above the window.

Then there's https://dxr.mozilla.org/mozilla-central/rev/4657041c6f77b36b1fb9647c28f53f4f51757360/widget/windows/nsNativeThemeWin.cpp#2149-2155 which seems to be setting that padding which pushes titlebar-content back down.

Two things that I'm noticing as a non-widget/gfx expert is that one of these is using the ScaleForFrameDPI thing, and one is not (but maybe that's OK given the kind of rect we're dealing with, or something?). The other thing I'm noticing is that one uses CYFRAME and one CXFRAME + CXPADDEDBORDER, which seems... surprising and potentially wrong?

I'll go get myself a cable later today so I can try looking at this with my surface pro as well.

In the meantime, Jonathan, do the position of #titlebar as being X pixels above the top of the maximized window, and the padding-top of the same element match up, so that #titlebar-content is actually flush with the top of the window, in the case where this isn't working well?

As already noted in my previous comment, I'm also wondering if the titlebar buttons are or are not behaving correctly here. If they are, it seems like #titlebar-content should indeed be flush with the top of the window, otherwise I'd expect the titlebar buttons to be misaligned, too.

Comment 20

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs Kruitbosch from comment #18)
> Something that I'm still not clear about, and I thought I asked before - are
> the titlebar buttons also cut off? Or are those in the right place and is it
> just the menubar/tabs ?

On the secondary (lo-dpi) screen, the titlebar buttons are in the right place, but get partially cut off (overlaid) on the bottom by the navbar strip, as they're oversized (because Windows doesn't scale them -- that's a documented feature, although I'd consider it a design bug). At least, that's the case on Win8.1.

> The sizing of the titlebar button box that contains the button is actually
> different on Windows 10, and NOT the result of the widget code.

Ah, interesting. I'm currently experimenting with fixes in the nsNativeThemeWin code to allow for the fact that Windows doesn't scale these elements as one might expect, and this does indeed make things better on Win8.1. I don't have as good/flexible a test setup for Win10, to compare that, but will see what I can work out.

Comment 21

[Jonathan Kew [:jfkthame]]

Attachment: patch 1 - Don't apply dpi-based scaling for window titlebar dimensions when on a secondary display, because windows doesn't scale it

OK, this is what I have so far: if we *don't* apply secondary-display DPI scaling to the titlebar dimensions in nsNativeThemeWin, things work a lot better. This makes a certain amount of sense, given that MSDN states that Windows doesn't scale the non-content part of the window when on a different-DPI monitor. This seems to fix things on Win8.1; not yet tested on Win10.

Comment 22

[Jonathan Kew [:jfkthame]]

Looks good on Win10 too, afaics; I don't have a configuration that exactly matches what :dcamp was using when this was originally reported, but I can reproduce similar issues with my TV hooked up to a netbook via HDMI, and displays set to differing resolutions. And fixing (removing) the titlebar scaling seems to be the key to fixing this.

It's not clear to me whether it would make better sense for some of the other widget dimensions to also be treated in this way -- like the NS_THEME_WINDOW_BUTTON_* widgets, as they're drawn without scaling by Windows AFAICT -- but in my testing so far, tinkering with those either had no visible effect, or made things worse again (e.g. pushing the window content area down much too far). So as a first step, I suggest we do the minimum fix here that resolves the immediately-visible issue; we can follow up with further adjustments if more testing and a better understanding indicates they may be necessary.

I've pushed a build with this patch:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=95fae4a54bd9

:dcamp, if you could give it a try when ready, and confirm whether this fixes the bug for you, that would be great -- thanks.

Comment 23

[Jonathan Kew [:jfkthame]]

Just FTR, the fact that the non-client area of the window (specifically, the titlebar is what concerns us here) is NOT scaled according to the per-monitor DPI -- even for applications that are per-monitor DPI aware, and therefore rescale their window contents -- is documented on MSDN here:
https://msdn.microsoft.com/en-gb/library/windows/desktop/dn469266(v=vs.85).aspx#categories_of_applications
"Note that the non-client area of a per monitor–DPI aware application is not scaled by Windows, and will appear proportionately smaller on a high DPI display." [Or bigger on a low DPI display, in the scenario of a hi-dpi laptop as primary display with a lo-dpi external monitor.]

I'm not the only one who thinks this behavior is bogus, FWIW:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0743317b-95d2-4f16-b122-5160fa9f73bf/nonclient-area-in-per-monitor-aware-applications?forum=vcgeneral

But at least for now, that's how Windows works and we just have to live with it.

Comment 24

[Jonathan Kew [:jfkthame]]

Comment on attachment 8728369 [details] [diff] [review]
patch 1 - Don't apply dpi-based scaling for window titlebar dimensions when on a secondary display, because windows doesn't scale it

So this is simply reverting a couple of the changes from patch 5 in bug 890156, because the titlebar dimensions don't actually respect DPI in this way.

Comment 25

[Masatoshi Kimura [:emk]]

Although $(VSInstallDir)\DIA SDK\include has dia2.h, MozillaBuild doesn't add it to $INCLUDE.

Comment 26

[Masatoshi Kimura [:emk]]

Sorry, wrong bug.

Comment 27

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/68cabbc58a91b978dc04c365294cf5ef6a9e8375
Bug 1249496 - Don't apply dpi-based scaling for window titlebar dimensions when on a secondary display, because windows doesn't scale it. r=emk

Comment 28

[Bogdan Maris, Desktop QA]

Attachment: Tabs overlapping

I just tested on Windows 8.1 with the try build from comment 22 and I think this did not fixed the other issue I encountered with tabs overlapping Close/Maximise/Minimise buttons: 

Testing was done with Latest Nightly 48.0a1 on Windows 8.1 (4k and low rez monitors) 
Attached is a screenshot of this.

Comment 29

[Bogdan Maris, Desktop QA]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #28)
> Attached is a screenshot of this.

Forgot to mention that Firefox from the left is the Try build and from the right is Latest Nightly.

Comment 30

[:Gijs (he/him)]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #28)
> Created attachment 8729423 [details]
> Tabs overlapping
> 
> I just tested on Windows 8.1 with the try build from comment 22 and I think
> this did not fixed the other issue I encountered with tabs overlapping
> Close/Maximise/Minimise buttons: 
> 
> Testing was done with Latest Nightly 48.0a1 on Windows 8.1 (4k and low rez
> monitors) 
> Attached is a screenshot of this.

This is technically not really the same bug as this one, but Jonathan, maybe this is fixable if we remove the ScaleForFrameDPI call for the:

     case NS_THEME_WINDOW_BUTTON_BOX:
     case NS_THEME_WINDOW_BUTTON_BOX_MAXIMIZED:

calls, too?

Comment 31

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs Kruitbosch from comment #30)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #28)
> > Created attachment 8729423 [details]
> > Tabs overlapping
> > 
> > I just tested on Windows 8.1 with the try build from comment 22 and I think
> > this did not fixed the other issue I encountered with tabs overlapping
> > Close/Maximise/Minimise buttons: 
> > 
> > Testing was done with Latest Nightly 48.0a1 on Windows 8.1 (4k and low rez
> > monitors) 
> > Attached is a screenshot of this.
> 
> This is technically not really the same bug as this one, but Jonathan, maybe
> this is fixable if we remove the ScaleForFrameDPI call for the:
> 
>      case NS_THEME_WINDOW_BUTTON_BOX:
>      case NS_THEME_WINDOW_BUTTON_BOX_MAXIMIZED:
> 
> calls, too?

Possibly. I did experiment a bit in this area (see also comment 22), but need to test some more to figure out if that's an adequate solution.

Comment 32

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/68cabbc58a91

Comment 34

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #31)
> (In reply to :Gijs Kruitbosch from comment #30)
> > (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #28)
> > > Created attachment 8729423 [details]
> > > Tabs overlapping
> > > 
> > > I just tested on Windows 8.1 with the try build from comment 22 and I think
> > > this did not fixed the other issue I encountered with tabs overlapping
> > > Close/Maximise/Minimise buttons: 
> > > 
> > > Testing was done with Latest Nightly 48.0a1 on Windows 8.1 (4k and low rez
> > > monitors) 
> > > Attached is a screenshot of this.
> > 
> > This is technically not really the same bug as this one, but Jonathan, maybe
> > this is fixable if we remove the ScaleForFrameDPI call for the:
> > 
> >      case NS_THEME_WINDOW_BUTTON_BOX:
> >      case NS_THEME_WINDOW_BUTTON_BOX_MAXIMIZED:
> > 
> > calls, too?
> 
> Possibly. I did experiment a bit in this area (see also comment 22), but
> need to test some more to figure out if that's an adequate solution.

Did a followup get filed for this?

Comment 35

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs Kruitbosch from comment #34)
> Did a followup get filed for this?

Not yet; it's in my mind but I haven't pursued it yet, working on higher-priority ones. If you'd like to file a bug so it's on record, that would be great.

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Jonathan, should we uplift this to Aurora 47?

Comment 37

[Jonathan Kew [:jfkthame]]

Comment on attachment 8728369 [details] [diff] [review]
patch 1 - Don't apply dpi-based scaling for window titlebar dimensions when on a secondary display, because windows doesn't scale it

Yes, we should -- it's a relatively minor cosmetic issue, but it's also a simple patch and has been on Nightly for quite a while now.

Approval Request Comment
[Feature/regressing bug #]: 890156

[User impact if declined]: a few pixels may be cut off the menus or tabs at the top of a maximized window on secondary monitor

[Describe test coverage new/current, TreeHerder]: on Nightly for a month now without problems observed (we don't have automated tests for multi-screen mixed-dpi setups)

[Risks and why]: minimal - it's a trivial patch that just affects scaling of a couple of Windows theme metrics, nothing else

[String/UUID change made/needed]: none

Comment 38

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8728369 [details] [diff] [review]
patch 1 - Don't apply dpi-based scaling for window titlebar dimensions when on a secondary display, because windows doesn't scale it

Improves per-monitor DPI experience, Aurora47+

Comment 39

[Jonathan Kew [:jfkthame]]

https://treeherder.mozilla.org/#/jobs?repo=mozilla-aurora&revision=71c303fbd010

Comment 40

[Jonathan Kew [:jfkthame]]

oops, I meant to paste:
https://hg.mozilla.org/releases/mozilla-aurora/rev/71c303fbd010

Comment 41

[Bogdan Maris, Desktop QA]

I don't have the necessary setup (similar to the one described in comment 0) to reproduce the initial issue. 
Dave, would you please see if the initial issue can be seen using Firefox 47 beta 8?

https://archive.mozilla.org/pub/firefox/candidates/47.0b8-candidates/build1/win64/en-US/

Comment 42

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I reproduced this bug using Fx47.0a1 build(20160218030349).
I tried reproducing this bug using Fx48.0b2 build(20160620091522) on Windows 10x64, Windows 8.1 x64, Windows 7x64, Ubuntu 10.04 x86 and Mac OS X10.10; I can confirm that the bug is partially fixed.

There is still an issue with Windows 10, if the menu bar is minimized and the menu bar active, the overlap persists.

Sreenshot: http://imgur.com/xv7bTLv

Filled bug: 1281778