User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160202030232 Steps to reproduce: I have 2 monitors connected to my laptop. If I maximize the window on the laptop screen, the Maximize, Minimize and Close buttons don't work. If I maximize it on monitor connected, it works ok.

Does it work with the current release (44)?

Yes, it works with current version, just the Nightly is affected.

In addition, did you test with e10s enabled and disabled in Nightly? Same issue? If yes, could you install the tool mozregression to find a regression range. See http://mozilla.github.io/mozregression/ for details and doc (you need python 2.7) You can use the command-line version and run the command "mozregression --good=44"

Same issue with e10s on/off. I will try the to find the regression range.

Ok, hope this will help you, spent 2 hours testing it:) 60:58.24 LOG: MainThread main INFO Oh noes, no (more) inbound revisions :( 60:58.24 LOG: MainThread Bisector INFO Last good revision: 98756a36223c1a2b51cd0 368736b728429038caf 60:58.24 LOG: MainThread Bisector INFO First bad revision: a9f9b36c1a2eec7626e6b 749e46ab0a8bf3323e2 60:58.24 LOG: MainThread Bisector INFO Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=98756a 36223c1a2b51cd0368736b728429038caf&tochange=a9f9b36c1a2eec7626e6b749e46ab0a8bf33 23e2

Tracking since this is a regression in 46.

Thank you for getting the regression range, beastieboss! This should be fixed in nightly 47 now (from bug 890156). But, can you let me know (with needinfo below this comment box) if you still see the problem? Sadly, wontfixing for 46 since there were conflicts trying to fix this in aurora, and we don't want to rush them. It seems to be a problem with particular hardware configurations.

If it regressed from bug 890156, I believe firefox46 should be unaffected, and firefox47 should still be affected since bug 890156 was backed out for 46, and no evidence shows this has been fixed since the regression.

Specifically, this is caused by the "part 9" patch in bug 890156. That patch was trying to address the problem of the window frame being slightly offset (leading to clipping of menus, etc, or to excess padding above them) when the window is maximized on a display with non-system DPI. However, there are a couple of issues with it. First, it doesn't work correctly in all situations; bug 1249496 shows a case where we're still getting it wrong. (And just changing its use of WinUtils::LogToPhysFactor(WinUtils::GetPrimaryMonitor()) to WinUtils::SystemScaleFactor(), while probably the right thing, isn't sufficient to fix that.) And second, it seems that altering the value of mNonClientOffset.top here by *any* amount -- even just one pixel larger or smaller -- causes the minimize/maximize/close buttons to become completely non-functional: minimize/maximize don't highlight when the mouse hovers over them, and none of the buttons work when clicked. (Double-clicking anywhere in their area will therefore "restore" (un-maximize) the window, but that's just because it acts as a double-click on the frame.) I haven't tracked down *why* any such adjustment makes the buttons non-functional, but given the combination of this issue and bug 1249496, I think we should simply back out that patch from m-c. That will fix this bug and restore the functionality of the buttons. It won't fix bug 1249496 -- if anything, that kind of visual glitch will become easier to reproduce in more cases -- but we can start afresh with trying to find a correct fix there.

https://hg.mozilla.org/integration/mozilla-inbound/rev/e3a41a0486eebca77e59e90d1585ffe9c53e4851 Bug 1245442 - Backout cset 9bde73f95ead (part 9 from bug 890156) for breaking the minimize/maximize/close buttons when a window is maximized on a monitor with non-system DPI. r=emk

It seems "backout" is a keyword stopping a bug from being marked FIXED by sheriffs :)

I don't have the necessary setup (similar to the one described in comment 0) to reproduce the initial issue. beastieboss 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/