Affected versions

• Firefox 77.0b2
• Firefox 78.0a1

Affected platforms

• Windows 10 x64

Preconditions:
1- Download template files from https://github.com/mozilla/policy-templates then extract it
2- Copy the two admx files [firefox.admx and mozilla.admx] to C:\Windows\PolicyDefinitions
3- Copy the two adml files [firefox.adml and mozilla.adml] to C:\Windows\PolicyDefinitions\en-US
4- Click the start button and type gpedit.msc into the search box and hit enter
5- On gpedit.msc, go to User Configurations-> Administrative Templates -> Mozilla >Firefox

Steps to reproduce

1. Double click on "Clear all data when browser is closed (Moved)" and select "Enabled" and press [OK].
2. Open Firefox with a clean profile.
3. Go to cnn.com and navigate on the page.
4. Search "dog" in the url-bar and search "cat" in the search-bar.
5. Open a new tab and close all the other tabs.
6. Close and reopen Firefox.
7. Go to about:cache in an new tab and verify there are no cache entries to the memory.

Expected result

• Caches are cleared.

Actual result

• Memory chache have a different value than 0. Sometimes you have to refresh the page.

Regression range

• I can't reproduce the issue on Firefox 76.0. I will be back with a regression as soon as possible.

Additional Notes:

• As far as we can tell the issue is reproducing only on Windows 10.

Regression range:
Last good: 2019-06-22
First bad: 2019-06-23
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f7ec497fd3334e98072da15e81f44ebafa72c15a&tochange=bfee60ff0a54cadfdedd541a8607a56fd1959df2
I am not sure if this pushlog helps, but this is the result I got and I checked it twice.

Not likely to be the correct range.

Hi Oana, Would you be able to track down/or confirm a regression range for this one?

Yes, that is the correct range, except the year (I apologize for that).
Regression range:
Last good: 2019-06-22
First bad: 2019-06-23

I can't reproduce the issue before 2019-06-22. The pushlog I am not so sure it's correct because I had to create it manually. But I am confident that the range is correct.

I was able to reproduce the issue using Firefox 78.0a1 (20200521093657) on Ubuntu 18.04.

Alexandru, are you perhaps able to get a more precise regression range?

I ran a regression range with mozregression on Windows 10x64 using system policies (Clear all data when browser is closed). The only thing I did different was at step 6 where I restarted Firefox (not closing/opening). For good builds, after restarting(step6) and going to about:cache Number of entries was 0 and for bad builds Number of entries was 1.
I got this regression range:
Last good revision: eda066bb80dd2b29ec31d17fcc59a9053cbc418d
First bad revision: 32cd5ce6a44ba03ad9757a36f47994b09184d041
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=eda066bb80dd2b29ec31d17fcc59a9053cbc418d&tochange=32cd5ce6a44ba03ad9757a36f47994b09184d041
I hope it helps.

The description of the bug is confusing. You don't have to set "Clear all data when browser is closed" to clear memory cache during shutdown. Memory cache isn't persistent, so the content is always lost during shutdown. If there is something in memory cache after startup, it's because of browser activity during startup. Please attach some screenshots to make clear what the problem is.

I did a video with the steps to reproduce the issue. These steps were taken after the precondition was met. I hope it will be more clear now.

(In reply to Oana Botisan, Desktop Release QA from comment #9)

Created attachment 9170668 [details]
chache remains.gif

I did a video with the steps to reproduce the issue. These steps were taken after the precondition was met. I hope it will be more clear now.

Using about:cache to check if all cache entries are cleared might not be a good idea, since we could already create some entries during browser startup. I think the best way is to check if all files in profile-default/cache2/entries are cleared after shutdown.

Oana, could you check again? Thanks.

I checked and not all the files are deleted from cache2 folder. Please look at the attached image. Four out of five times, these three files were still left.

Those files are not cache entries. They are created when context eviction is started and removed when the eviction finishes. The eviction process takes some time and if Firefox would crash during the eviction, we wouldn't know on the next start which entries should be removed and which not. These files have all this information encoded in their names, so the eviction can continue on the next start after a forced shutdown or a crash.

(In reply to Michal Novotny [:michal] from comment #12)

Those files are not cache entries. They are created when context eviction is started and removed when the eviction finishes. The eviction process takes some time and if Firefox would crash during the eviction, we wouldn't know on the next start which entries should be removed and which not. These files have all this information encoded in their names, so the eviction can continue on the next start after a forced shutdown or a crash.

Taking this fact in consideration then the bug might be invalid.
But also... isn't it a problem tha fact that sometimes even those files are deleted? It is intermittent, but it might cause some issues.

I think this is invalid.