Created attachment 8879584 [details] Troubleshooting Information.xht (about:support) User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170518000419 Steps to reproduce: Sorry I can't see a pattern: the issue appears randomly, regardless of how long Firefox or Windows has been running or how many tabs or windows are open. PERHAPS, but I'm not 100% sure, this happens after the power settings timeout turns the screen off. Even so, it doesn't always happen: most of the times, returning from screen off, Firefox is OK. Actual results: The rendered part of the windows (all windows, all tabs) go completely black. This DOES NOT happen for info tabs like about:support. Report from this page shows a graphics system reset: failures: CP+[GFX1-]: (gfxWindowsPlatform) Detected device reset: 1 (full about:support page attached) This certainly happens with hardware acceleration ON, not sure if I've seen this with hardware acceleration OFF. This has been happening for the last few versions of Firefox, at least for a couple of months, maybe longer. Possibly started after switching from AMD video card to Nvidia. The system is Windows 10, kept constantly fully updated, latest video drivers (but it happened also with older drivers) Expected results: erm... the windows should be rendered correctly, even after the video card suffers a reset. Firefox seemingly fails to reconnect to the video subsystem.
possible duplicate of bugs 1298009 and/or 1096864
Component: Untriaged → Graphics
Product: Firefox → Core
If your graphics driver crashes, and Firefox displays some graphics issues after that, you need to restart the browser, it has been always like that.
That's lazy programming. If the program gets into a failure state, it should either fix it or restart on its own, but not leave the choice to the user.
Indeed, because the driver resets are happening in "random" parts of the code, we have to deal with those one by one. Restarting the browser is a bit drastic, as you can lose information, though I appreciate that having the screen stop displaying is not leaving it in a useful state, and that restart and data loss is inevitable. This is useful, but not necessarily actionable - a workflow as to what reproduces the problem would help, and funnily enough, a crash report may contain more information for figuring out what's going on.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 months ago
Priority: -- → P3
Resolution: --- → DUPLICATE
Duplicate of bug: 1298009
You need to log in before you can comment on or make changes to this bug.