Closed Bug 1536396 Opened 5 years ago Closed 3 years ago

Firefox interface disappears after waking up the computer


(Core :: Graphics, defect, P3)

65 Branch





(Reporter: stalliondrift, Unassigned)


User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

  1. Use Firefox normally just like every day.
  2. Put the computer to sleep with Firefox running.
  3. Wake it up 8 hours later.

Actual results:

The whole Firefox interface disappeared leaving only the background image I have chosen for it. For clarity I made 2 screenshots: 1 with the normal look ( of my Firefox and 1 of my Firefox whenever the interface bug happens (

P.S. Firefox 61.0.1 doesn't have this bug.

Expected results:

The interface shouldn't disappear.

I couldn't reproduce this issue after waking the system after 5 hrs on

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Placing this under core:Layout, so someone can look into this. Please feel free to change to more appropriate component. Thanks!

Component: Untriaged → Layout
Product: Firefox → Core

Are you using WebRender or some other non-default graphics pref or such? Attaching a copy of about:support would be helpful.

This looks like either Graphics or Widget.

Component: Layout → Graphics

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Are you using WebRender or some other non-default graphics pref or such? Attaching a copy of about:support would be helpful.

This looks like either Graphics or Widget.

Only "layers.acceleration.force-enabled" set to "true" which kinda relates to web rendering (removes screen tearing when scrolling up and down). I'm using this setting for 2 years or so and before FF65 there was no problem with the browser.

Either I'm blind or I really can't see an option to attach text files, so I'm uploading the about:support to zippyshare:

Priority: -- → P3

I am experiencing this bug as well and hopefully can provide some additional information.

Firstly, steps to reproduce (fresh profile, 2019-30-12 nightly build):

  1. In about:config set layers.acceleration.force-enabled to true, then
  2. Restart FF
  3. Suspend computer
  4. Wake the computer
  5. Go to YouTube and play any video. After a few seconds interface will start disappearing

Here's a screenshot:

Note that layers.acceleration.force-enabled set to true is crucial for this to happen. Similarly to OP, with this setting set to false (which is the default) I am experiencing lots of screen tearing. I started experiencing this problem after upgrading from previous ESR release (based on 60.x branch) to the latest ESR release (based on 68.x) branch, which means this must have been introduced somewhere in between. Also, it sufices to just put computer to sleep, it doesn't have to be for hours. Finally, this only starts to happen after playing a video (something on YT or a webm video) - as long as I just browse pages without videos everything displays fine.

My platform is the latest Debian Buster 10.2 with NVidia proprietary driver, version 418.74. Let me know if more information is required. Right now I am seriously considering downgrading back to an older ESR, since the screen tearing is just so bad (with layers.acceleration.force-enabled = false) and I can't afford to restart FF every time I put my laptop to sleep (which is mutliple times a day).

On my end it happens even without any tab open - as soon as I move the mouse cursor over the browser interface and it disappears. That's why ever since this bug appeared I'm keeping my browser at 61.0.1 - this version doesn't have that bug and I won't update it till this problem is fixed.
At first I thought it was an addon responsible but even without addons the interface disappears completely.

I just did some testing to find out which version introduced the breakage. Assuming layers.acceleration.force-enabled set to true I have found that:

62 - everything works
63 - FF freezes a few moments after waking from suspend. No interacting with the browser required. Note also that this is a freeze, i.e. FF becomes completely unresponsive and needs to be killed.
64 - interface becomes corrupted after waking from suspend. This is not a freeze, I can still use keyboard shortcuts to close the tabs or the while browser.

So it seems that maybe 63 introduced a bug that broke waking from suspend and then that bug got partially fixed in 64?

Also, there's a tool called mozgression:

that can be used to do a more detailed bisect of the nightly builds. Unfortunately I can't get it to install on my Debian (getting an error "pyopenssl 19.1.0 has requirement cryptography>=2.8, but you'll have cryptography 2.6.1 which is incompatible"). rado84-bgz, perhaps you could give it a try?

I can't. I installed the required package but when I update Firefox to the current build which is 71, I keep getting only the same message - every time I try to load any page I get a tab with the message a browser restart is required, so I do it. But after the browser restart the same tab with the same message appears and I'm being put into a neverending loop of manual browser restarts. So I can't do the required bisect because apparently updating from 61 to 71 something breaks badly. I checked profile path in the profile.ini file and everything is fine there. I even tried a complete removal of Firefox 61 from the system and installing 71 as if it was never part of my system but even without copying my profile to the new installation, it still won't load any page and keeps asking for browser restart.

I can see now that I haven't mentioned my system information in my first post on this topic, so I'm posting it now:

[rado@arch]: ~>$ sysinfo
OS: Arch Linux
Kernel: x86_64 Linux 5.4.7-arch1-1
Uptime: 1d 36m
Packages: 1195
Shell: bash
Resolution: 1920x1080
DE: Cinnamon 4.4.6
WM: Muffin
WM Theme: Mint-Y-Brownish_for-Cinnamon-v4_by-rado84 (Cinnamox-Rhino)
GTK Theme: Mint-Y-Brownish_for-Cinnamon-v4_by-rado84 [GTK2/3]
Icon Theme: Humanity-Dark
Font: Noto Sans Bold 10
Disk: 600G / 1,5T (42%)
CPU: Intel Core i7-4770 @ 8x 3.9GHz [29.0°C]
GPU: GeForce GTX 1050 Ti
RAM: 2467MiB / 32038MiB

Have you tried removing (read: renaming/moving somewhere else so that you can restore it later) the ~/.mozilla directory? That should give you a clean profile.

Yep, I did. This is what happens with a clean profile (meaning whatever profile the browser creates). As you can see, only a small parts of the things actually open and even if they do, the browser doesn't switch to the new tab at all.

The installed packages are "firefox" and "firefox-i18n-bg" which in Arch's case means the latest possible (not ESR).

Adding some info that may help the devs and/or any user experiencing this problem: I just did this - with Firefox 72 being installed I manually removed /usr/lib/firefox/ directory and copied over the ESR firefox ( ) and put the computer to sleep. For the moment (FF ESR 68.4.1) this problem DOESN'T seem to happen after waking up the computer. layers.acceleration.force-enabled is as always set to true.

I celebrated too soon - the disappearing interface just happened with FF-ESR 68 and this time it was for no apparent reason. I was simply surfing the internet when this happened:

OK, the problem from my last few posts was fixed - too long story to tell here. Now only remains the disappearing interface to be fixed which is still happening in version 72. Sometimes it happens even without an obvious reason. For instance, before putting the computer to sleep I have closed Firefox and when I wake it up, I run Firefox again. Then, at some point, the interface disappears and the browser becomes irresponsive and the only thing I can do is to restart it until the next time the interface disappears.

And here are the results of some testing I did yesterday but I didn't have the time to post the results here. For a few years I've been using layers.acceleration.force-enabled set to true in order to prevent tearing in the browser when scrolling pages. But it seems that at some point this setting has become in conflict with the nvidia's setting "Force full composition pipeline" which leads to both functions cancelling each other which also leads to a disappearing interface.

Force full composition pipeline ON + layers.acceleration.force-enabled "false" = no tearing, no disappearing interface.
Force full composition pipeline ON + layers.acceleration.force-enabled "true" = no tearing, disappearing interface.
Force full composition pipeline OFF + layers.acceleration.force-enabled "false" = tearing everywhere, no disappearing interface.
Force full composition pipeline OFF + layers.acceleration.force-enabled "true" = no tearing, disappearing interface.

So it seems that with just Force full composition pipeline being turned on the problem is fixed. I can easily make the pipelining option to remain permanent but less tech savy users won't know how to do that and it would be good to fix that conflict for them.

In case someone doesn't know: Force full composition pipeline is responsible for flipping in Linux which is like vertical sync in Windows. Without flipping there's a lot of tearing while playing games and while watching movies. No flipping also means tearing while scrolling pages. That doesn't happen 100% of the time but it happens nevertheless. In the case with games (native Linux games) it also means a lot of graphical stuttering, especially if the game's vertical sync option is enabled but the Linux's vertical sync is disabled (FFCP is OFF).

Unfortunately, this does not work for me. I have Force full composition pipeline ON + layers.acceleration.force-enabled "false" and I still experience screen tearing. Tested on today's nightly build.

IDK what a nightly build is but it works for me. Once the page is fully loaded, scrolling is as smooth as before. If I don't wait for the page to fully load, tearing will happen. But I have a fast connection, so pages load pretty quickly.
I also tried this in KDE and since KDE uses Wayland instead of Xorg, there's no tearing in KDE with FFCP ON and layers.acceleration OFF. But if you're using Windows, I have no idea how it is there.

Nightly builds are snapshots of FF development branch that are build on a daily basis and made available to the users. So by testing a nightly build I am essentially testing the latest development version without having to build it myself from the repo. You can get a nightly build from here:

I am on Linux and using Xorg server. So perhaps the difference comes from Wayland vs. XOrg?

I tried KDE just for the test, otherwise I'm using Cinnamon DE which uses Xorg. But I can't explain why tearing disappeared on my end while remaining on yours when both of us use Xorg.

Which version of nvidia driver do you have? I'm on 418.74 and I would be guessing this is not the latest one (I'm on Debian, which tends to lag behind).


I'm not sure if this is the right issue as the failures in my interface do look quite a bit different from the reporter but I'm also missing interface elements after waking up. Generally it is page title in the tabs but sometimes its quite a bit worse and lots of the chrome is missing any icons and you kinda have to click around blindly or use killall to restart the browser and preserve my session.

I do not have force full composition enabled and layers.acceleration.force-enabled is the default false. This is a laptop and the display is a "Prime" display but I have the profile set to performance(nvidia only). Ubuntu 20.04 with nvidia proprietary 435.21

Obviously its a very different project but this sounds a lot like this bug from Gnome where Nvidia systems would end up with corrupt data in buffers after resume. My understanding was that maybe nvidia drivers do not have the best behavior when waking up. :( Maybe some of the discussions or changes are helpful to a developer.

This system has had problems with nouveau in the past but for the gnome issue it seemed to be specific to the nvidia blob drivers so testing under nouveau might be a way to narrow it down or work around it.

I doubt the problem is in the driver. My nvidia driver is 440.82 on Arch Linux with FFC enabled and layers acceleration (LA) disabled. For as long as the LA option is disabled, the FF interface is fine. The moment I enable LA the disappearing interface returns within 5 minutes from enabling it, even without putting the computer to sleep.

I think James is right with suggestion about the nvidia driver being involved here. Sadly, nVidia's proprietary drivers are notoriously bad with resuming from suspend. For example, I can reproduce a bug very similar to this one on Chromium, except that on Chromium only the web page disappears after waking from suspend (not the application interface) and correct rendering can be recovered by refreshing the web page. With Vivaldi (Chromium based browser) the application window is black for a split second and then it displays correctly.

Up until now I've been working on Firefox 62 since it was the last version that didn't have the problem. I recently upgraded to 78-ESR and spent some time debugging this again. Sadly, there's no improvement (also tested 81-nightly) and without hardware acceleration the tearing in videos is so bad it makes the browser unusable. For now I'm moving away from Firefox and using Vivaldi instead. Hopefully this will get resolved one day.

Any updates?

I have same issue on RTX 2060 Mobile (440.10) and Pop-OS 20.04

I am also experiencing this issue on Manjaro with kernel 5.8.18-1 using Nvidia Quadro P520 with driver 440.100 on Firefox 82.0.3

(In reply to tytheguy95 from comment #25)

I am also experiencing this issue on Manjaro with kernel 5.8.18-1 using Nvidia Quadro P520 with driver 440.100 on Firefox 82.0.3

layers.acceleration.force-enabled --> disable

and it won't happen anymore. Unfortunately, this will cause screen tearing when scrolling in pages. This started with FF 63 and 20 versions later Mozilla still refuse to fix it. I doubt they ever will. They already demonstrated they do whatever they want and don't give a f**k about what the users want.

It's more complicated than Mozilla not wanting to fix this. The problem unfortunately lies in nVidia drivers being unable to properly resume from suspend. It's not just FF that's affected by this. Chrome and chrome-based browsers (e.g. Vivaldi) are experiencing the exact same issue. It's nVidia who should fix the problem and if you look at their forum you'll see there are multiple topics reporting suspend issues. nVidia drivers have an experimental way of waking from suspend that you might want to try out:

It didn't work for me (i.e. I couldn't get it to work) but maybe it will work for you.

Right now I am running rtx2060 455.28 and pop os 20.10 and the issue went away. I think it disappeared after some driver update several weeks ago, not sure which one exactly.

(In reply to jwstolarek from comment #27)

The problem unfortunately lies in nVidia drivers being unable to properly resume from suspend.

I doubt that. I have an old copy of FF 61.0.1 with my profile settings. The current nvidia driver is 455.38 and 61.0.1 doesn't suffer from that bug. FF 63 also doesn't suffer from it. Only 65+.

I was testing with firefox(84) and chromium
nvidia driver 450 - firefox starts disappearing, chromium has no such issue.

nvidia driver 455.38 - same results, Firefox disappearing act is still there. Which version of Firefox are you using? (I disabled all the plug-ins) I have Ubuntu 20.04, Firefox 84, Gnome G

Please test latest (bug 1682876): Open about:config, set gfx.webrender.all to true and restart Nightly to enable the new hardware rendering engine.

I just tested the 86.0a1 (2020-12-20) nightly and the problem seems to be fixed regardless of gfx.webrender.all setting, i.e. interface does not disappear after waking from suspend even if gfx.webrender.all is set to false.

Thanks for testing! :) Please set gfx.webrender.all to true and keep it enabled if possible.
If you encounter problems, please don't hesitate to file a WebRender bug:

Closed: 3 years ago
Resolution: --- → DUPLICATE

Thanks for fixing this (finally!). I don't use nightly on a daily basis (no pun intended), so I can't really test this continuously. All I can confirm is that I was unable to reproduce the problem despite my best efforts and conducting about 10-15 suspends. I'm waiting for this to finally make it to a stable version - ideally, a future ESR release, since that's what I tend to use.

It seems to be fixed but only if you DON'T enable "layers.acceleration.force-enabled" by setting it to "true". The moment you enable that, everything disappears almost instantly - there's no need to even suspend the system.
(what you can see here is part of my desktop inside Firefox 85 - freshly updated)

So it's partially fixed. And I could use this bug being fixed for the layers acceleration option because that's the only way to remove screen tearing when scrolling or when watching fullscreen YouTube videos. Driver version is 450.57, if it matters.

Using latest FF 85 with Intel drivers on Ubuntu 20.04, "layers.acceleration.force-enabled" set to "false", "gfx.webrender.all" set to "true" and still UI corrupts after a resume or wake-up.

You need to log in before you can comment on or make changes to this bug.