Steps to reproduce for me: 1. open Firefox, and move the window to a HiDPI display 2. close Firefox 3. open Firefox, and it should be opened in the HiDPI display 4. move the window to a LoDPI display Expected result: everything works just fine Actual result: the window turns black, nothing is displayed inside it. But it is still responsive, you can click the hamburger button to open the main menu (which is visible), and context menu is also usable. This doesn't seem to be a regression. I can reproduce this issue since bug 890156 which introduced per-monitor DPI support. For reference, I have three monitors: 1. HiDPI 250% laptop monitor 2. LoDPI 100% monitor (primary monitor) 3. LoDPI 100% monitor

It seems any window ever moved to the HiDPI monitor will become black when moved back to the LoDPI monitor.

It seems that the scaling percentage doesn't matter. As far as my display 1 and display 2 have different scaling percentage, this happens, but if I move the window between display 2 and display 3, no matter whether there is scaling difference, this doesn't happen.

A possible explanation is that, display 1 is on the integrated Intel graphics card, while display 2 and 3 are on the discrete NVIDIA graphics card. FWIW, Edge and Chrome (which both support per-monitor DPI as well) do not seem to have this issue on my machine, while all versions of Firefox are affected.

jfkthame, any thought here?

It sounds like this is a graphics problem related to your particular configuration of displays/cards/drivers, rather than a widget-level bug. Does disabling hardware acceleration make any difference? What about e10s?

Disabling hardware acceleration fixes this issue. Disabling e10s doesn't.

I think we should move this to Graphics and see what the team there thinks about it. I'd guess we're failing to properly update some level of the gfx stack (D2D targets or whatever) when the window moves between displays and drivers.

Is it possible to get an about:support dump after this happens? Even by some tricky means, like: keep about:support open, then after the screen goes black, refresh it and hit ctrl+a ctrl+c to grab the text. Or is Firefox completely unresponsive?

It is possible. I can even trigger the "Copy raw data to clipboard" via keyboard. But the content doesn't seem to change after turning black. The attached file is the raw data from about:support after the window turns black (which is identical to what it is before, though).

dvander, any thought about this? I have a local build with this bug reproducible, so if you have any idea about inserting some code somewhere to dump useful information, I can help as well.

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #10) > dvander, any thought about this? I have a local build with this bug > reproducible, so if you have any idea about inserting some code somewhere to > dump useful information, I can help as well. Darn, I don't see anything useful there. I was hoping we'd get a device reset message or something. It looks like DPI changes are handled here[1]. Maybe we should check that we actually hit this path, and that it's resulting in a new paint. [1] http://searchfox.org/mozilla-central/rev/12cf11303392edac9f1da0c02e3d9ad2ecc8f4d3/widget/windows/nsWindow.cpp#7139

That function is called correctly.

Another interesting thing is that, after the window turns black, if I move the window to the edge of two monitors (without triggering DPI change), the half on the HiDPI monitor would be visible, while the half on the LoDPI monitor keeps showing black. See the attached screenshot.

It seems to work now, and I checked with some previous version, and it seems they work as well, so presumably it is because of system upgrade and/or driver upgrade. Closing now.