1527503 - Firefox does not close immediately, but remains active in the background for several seconds using a lot of CPU.

Status: VERIFIED FIXED

(Core :: DOM: Service Workers, defect, P2)

Description

[Rival]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

After upgrading to firefox 65.0, when I close the firefox window, I noticed a huge increase in the amount of time firefox takes to completely shut down the processes.

Tested on Windows 10 64bit v.1803
Tested with an "old" profile.
Tested in safe mode.
Tested with new profile.
Also tried version 65.0.1 and 67.0a.
Test also performed on another computer with different hardware configuration.

Actual results:

As soon as I close firefox, Firefox closes the window but then passes some processes in the background and one of these uses a high percentage of CPU. (around 30% -40%).
After several seconds (from 3 seconds to about 2 minutes !!!) the processes finally close.

In this period of time if you try to reopen firefox, check the error box indicating that firefox is still active.

After you navigate to various sites, all the configurations tested start to take more and more time to close.
Instead NO problem with firefox 64 (and previous).

Expected results:

Immediate (or near) closure of all firefox processes such as versions prior to 65.

From my superficial investigation, the problem seems to be due to some problem in the storage of site data.
In fact the problem is amplified proportionally to the amount of data of the memorized sites.
For example, https://web.whatsapp.com, https://mail.google.com, https://drive.google.com, etc.,
they memorize a lot of data during use, and when they close firefox, they accentuate the problem.

By manually deleting the data of the sites stored by firefox in:
C: \ Users \ username \ AppData \ Roaming \ Mozilla \ Firefox \ Profiles \ xxxxxxxxxxxxx \ Storage \ Default
the closure returns to be immediate.
I believe and hope this clue is useful to you, to understand the cause of the problem. ;)

Simple temporary solution:
In Firefox, set the permissions exceptions on cookies for sites that store lots of data, such as "allow for session".

Comment 1

[Tom Tung [:tt, :ttung]]

It sounds like this is not related to local storage. In fact, it's more like bug 1487194. I'm going to move this to QuotaManager component.

Rival, could you do me a favor: going to [1] and checking the result of it? This website can test if your profile is healthy or not. Also, if you can provide the information in [2], that would be really appreciated. This is the initialization time of your profile, and such information would be really helpful for us to investigate the problem of shutting down. Thanks!

Note that if your result of [1] is not positive, then you won't have a data on [2]. The reason is that bad results in [1] mean your profile cannot be initialized, and thus you won't get the time of initialization.

Besides, the data in [2] will only be shown in a short period. So, I would suggest restarting the Firefox, then going to [1], and then check [2] if you cannot find the data in [2] and having a positive result for [1].

[1] https://firefox-storage-test.glitch.me/
[2] about:telemetry#search=QM_REPOSITORIES_INITIALIZATION_TIME

Comment 2

[Rival]

[1]
Overview:
Storage is working. This is the same version (65) as the last time you loaded this page.
Specific Subsystem Statuses:

LocalStorage
Good: Totally Working. (fullyOperational)
QuotaManager
Good: Totally Working. (fullyOperational)
IndexedDB
Good: Totally Working. (fullyOperational)
Cache API
Good: Totally Working. (fullyOperational)

[2]
QM_REPOSITORIES_INITIALIZATION_TIME
1 campioni, media = 13, somma = 13

9 | 0 0%
13 |######################### 1 100%
18 | 0 0%

---

I have already tried with a "clean" or new profile or with completely clean installations! Same problem.

For now all the PCs of the other users that I have tested have this problem ... after updating to firefox 65, the shutdown times of the browser have increased so scary.

Even though I have a relatively fast PC, I immediately realized the problem, I do not understand how it is possible that very few firefox users noticed this problem, where on their PC it was even more exaggerated. :/
On the internet, for example, I found only one link that talks about this same problem:
https://www.dedoimedo.com/computers/firefox-65-slow-close.html

Comment 3

[Tom Tung [:tt, :ttung]]

(In reply to Rival from comment #2)
Thanks for the information! I'm sorry to hear having problems on shutting down slowly.

[1]
Overview:
Storage is working. This is the same version (65) as the last time you loaded this page.
Specific Subsystem Statuses:

LocalStorage
Good: Totally Working. (fullyOperational)
QuotaManager
Good: Totally Working. (fullyOperational)
IndexedDB
Good: Totally Working. (fullyOperational)
Cache API
Good: Totally Working. (fullyOperational)

[2]
QM_REPOSITORIES_INITIALIZATION_TIME
1 campioni, media = 13, somma = 13

9 | 0 0%
13 |######################### 1 100%
18 | 0 0%

---

I have already tried with a "clean" or new profile or with completely clean installations! Same problem.

This looks like it's a fresh/an empty profile because your initilization time is rather short. And, shutting down slowly even with a new profile means it is not related to initialization.

Rival, just for ensuring I understand correctly (I felt like I misunderstood something), you mentioned that the closure returns to be immediate after clean the profile on comment#0. However, it seems that you have the same problem even with a completely clean installations? Could you elaborate more about this? Thanks!

I was suspecting the process of shutting down on initialization stuff taking too much time, and that's why cause the problem, but, right now, it seems we have some issues else.

Comment 4

[Rival]

I try to explain better ... with the steps taken with a test carried out by me with a new installation.

1. I install firefox 65

2. I open the browser

3. I close the browser

4. The browser closes all processes immediately (like firefox ver.64) - OK

5. Reopen the browser

6. I surf on various sites that do not save much data, only classic cookies.

7. I close the browser

8. The browser closes all processes immediately (like firefox ver.64) - OK

9. Reopen the browser

10. I use various sites that save a lot of data in addition to cookies, (for example: https://web.whatsapp.com, https://mail.google.com, https://drive.google.com, https://www.facebook.com, etc.)

11. I close the browser

12. The browser closes all the processes after several seconds (even minutes) and one of the processes uses about 30% of the CPU (the firefox ver.64 instead closed the processes immediately) - ISSUE

13. Reopen the browser

14. I close the browser

15. The browser closes all processes after several seconds and one of the processes uses about 30% of the CPU - ISSUE

16. I manually delete ONLY the data of the sites saved in the profile, present in the folder:
    "C:\Users\xxxxxxxx\AppData\Roaming\Mozilla\Firefox\Profiles\xxxxxxxxx\Storage\Default*"

17. I reopen the browser

18. I close the browser

19. The browser returns to close all processes immediately (as with firefox's version 64)! - OK

20. Reopen the browser

21. I use various sites that save a lot of data in addition to cookies.

22. I close the browser

23. The browser closes all the processes after several seconds and one of the processes uses about 30% of the CPU - ISSUE

Basically, the larger the amount of data on sites saved by Firefox (WebStorage?), and more Firefox 65 becomes slow (and "hungry" for energy) to shut down its processes.
Previous versions of Firefox did not have this annoying problem.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Have you turned on the "Delete cookies and site data when Firefox is closed" option like is documented at https://support.mozilla.org/en-US/kb/enable-and-disable-cookies-website-preferences#w_clear-cookies-when-you-close-firefox ?

That setting is expected to cause Firefox to spend time clearing your storage when you quit. This setting may also be reflected if you've set cookies/site-data storage elsewhere to "session only".

There's also a "Clear history when Firefox closes" option under history that can have similar results.

Comment 6

[Rival]

Negative, neither of these two options is activated, neither on my old profiles nor on those of a new installation.
(And anyway with the same profile and settings, firefox 64 and earlier, they never gave similar problems.)

In fact, you gave me an idea to get around the problem, and rule out doubts about the source of the problem. ;)

I selected "Clear history when Firefox closes", and in the related Settings, I ONLY selected "Offline Website Data".
The closure of Firefox 65 with this setting has become immediate!

Evidently, in version 65 of firefox, code was added that compromised the correct maintenance of offline site data, in the closing phase. (Check? Cleaning? Reordering? Sanitize? I do not know!)
This causes slowdowns and overloads, or perhaps even crash and corruption of data.

Comment 7

[Tom Tung [:tt, :ttung]]

(In reply to Rival from comment #4)
Thanks for explaining by stating the steps to reproduce.

6. I use various sites that save a lot of data in addition to cookies, (for example: https://web.whatsapp.com, https://mail.google.com, https://drive.google.com, https://www.facebook.com, etc.)

I just visited these websites by my daily-use Nightly, then checked my profile only under the default folder:

• https://web.whatsapp.com uses idb and cache
• https://mail.google.com uses idb and cache
• https://drive.google.com uses idb
• https://www.facebook.com uses idb and cache

Maybe problems are on idb or cache?

If you can reproduce that even after having visited there several times (means most IOs have been down), then there probably are issues on shutting down for ongoing databases, connections or something.

Basically, the larger the amount of data on sites saved by Firefox (WebStorage?), and more Firefox 65 becomes slow (and "hungry" for energy) to shut down its processes.
Previous versions of Firefox did not have this annoying problem.

Web Storage refers to local storage, IIUC. I guess I need more time to think about how can this happened.

Comment 8

[Rival]

(In reply to Tom Tung [:tt, :ttung] from comment #7)

I just visited these websites by my daily-use Nightly, then checked my profile only under the default folder:
...
Maybe problems are on idb or cache?

I would bet on cache. ;)

Comment 9

[Tom Tung [:tt, :ttung]]

Testing this by going to all 4 websites and then closing the Firefox on our Windows laptop (Lenovo). Firefox 65 close immediately on my laptop.

I guess this means, at least, not all Windows users having this issue.

Comment 10

[Tom Tung [:tt, :ttung]]

Hi Rival, sorry for pinging to you again.

So, could you check your "about:crashes" page to see whether those hangs are crashes or just something else? Thanks!

Comment 11

[Rival]

(In reply to Tom Tung [:tt, :ttung] from comment #10)

Hi Rival, sorry for pinging to you again.

So, could you check your "about:crashes" page to see whether those hangs are crashes or just something else? Thanks!

No problem, Tom, in fact I'm sorry if I did not answer you before.
I was a little busy these days.

However, I have not had any recent crashes, (only one, but it was caused by some "forcing" that I made to Firefox). ;)

Comment 12

[Rival]

Attachment: permissions.sqlite

Comment 13

[Rival]

After several tests, maybe I'm approaching the cause of the bug ...

It seems that the problem with the closure is directly proportional to the amount of "offline website data" stored AND the amount of the exception of the permissions on cookies and data sites.

I created a small file (permissions.sqlite), to be used in tests, for those with a profile with no or little exception of cookies and data sites. I have included many fictitious sites in exceptions just to highlight the problem.

• Replace "permissions.sqlite" of your profile with this: https://bugzilla.mozilla.org/attachment.cgi?id=9047184 ,(of course do not forget to make a copy of the original first to be able to restore it at the end of your tests). ;)

• Open Windows Task Manager (with "more details" enabled)

• Open Firefox.

• Browse to https://web.whatsapp.com to accumulate website data (it can also accumulate dozens of MB, depending on the media files displayed, in <profile> \ storage \ default \ https +++ web.whatsapp. com \ cache \ morgue)

• Close Firefox

• The Firefox window closes, but on the Windows Task Manager, you'll notice that the processes of Firefox are moving in the background, staying active for several seconds and one of these processes consumes about 30% of CPU all the time !!!

• Reopen Firefox

• Close Firefox

• The Firefox window closes, but you'll notice that the usual Firefox background processes, stay active for several seconds and consume CPU!

• The problem disappears if you clean "<profile> \ storage \ default \ https +++ web.whatsapp.com \ cache" OR delete all exceptions in cookies and date permissions.

The versions of Firefox prior to 65, instead closed all processes almost immediately regardless of the amount of offline website data and complexity of permissions.sqlite!

Comment 14

[Tom Tung [:tt, :ttung]]

(In reply to Rival from comment #13)

Thanks! I will check it later, but, at least, it seems that it's verified that's a cache's problem.

Comment 15

[Tom Tung [:tt, :ttung]]

(In reply to Tom Tung [:tt, :ttung] from comment #14)

(In reply to Rival from comment #13)
Thanks! I will check it later, but, at least, it seems that it's verified that's a cache's problem.

Unfortunately, I couldn't reproduce the issue with following steps on comment #13 on a windows laptop. (Perhaps, it's because I don't have much data on the whatsapp so that service worker doesn't need to fetch so many data from the network? But, I still have 256 bodies files on my morgue directory)

But, based on these steps, I guess it's a service worker / dom cache and permission.sqlite issue.

Comment 16

[Rival]

I recently tested the firefox nightly 68.0a1 (64 bit).
I don't know what changes to the code have influenced the issue,
but it seems that at the moment on this version the bug doesn't show up.

Comment 17

[Tom Tung [:tt, :ttung]]

(In reply to Rival from comment #16)

I recently tested the firefox nightly 68.0a1 (64 bit).
I don't know what changes to the code have influenced the issue,
but it seems that at the moment on this version the bug doesn't show up.

That's good news!

I'm going to close this bug because the reporter on comment 16 said that the original problem seems to be fixed on nightly 68. Please feel free to re-open this bug if the problem shows up again.

Comment 18

[Rival]

To complete the information, (also to help in the future, in case of reappearance of this bug), I add other tests performed:

Tested on Windows 10 64bit v.1803
firefox 64.x and earlier ----- NO affected
firefox 65.x ----------------- affected
firefox 66.x ----------------- affected
firefox 67.0 Nightly --------- affected
firefox 67.0 Beta ------------ NO affected
firefox 68.0 Nightly --------- NO affected

Tested on Ubuntu 19.04
firefox 66.0.3 ----------- affected
firefox 67.0 Beta -------- NO affected
firefox 68.0 Nightly ----- ??? (sorry no test)

So, to sum up, the operating system does not seem to influence this problem, and from the transition to the beta channel, even in version 67 it seems that the bug has been solved. ;)

I suppose the code that "unintentionally" solved this bug was included in the 67 Nigthly version, after 12 February 2019.

Comment 19

[Alexandru Trif, Desktop QA [:atrif]]

Hello!
Reproduced the issue using Firefox 67.0a1 (20190212095015) on Windows 10x64 using steps from comment 13.

The issue is verified fixed using the same steps with Firefox 68.0b14 (20190627143605) on Windows 10x64 (no Firefox background processes, stay active after closing the browser).