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

Steps to reproduce:

• load a HTML form via https
• submit the form with POST -> the returned page also contains a form
• submit the returned form with POST
• return to previous page with the Back button

Actual results:

The cache is not used : form is submitted again to get a fresh response
The submit confirmation is not displayed
The bug is intermittent : sometimes the cache is used

Expected results:

Cache should be used : header contains Cache-Control: private; Max-age=604800
This happened first on Dec 2 2021
Tried various Cache-Control headers : no way

May be the same reason as Bug 1745851

This happened first with Firefox 95

The Bugbug bot thinks this bug should belong to the 'Core::Networking: Cache' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Do you have a test that we can use?

Test site :
https://evasoft.fr/eva/demo-social.cgi
User : firefox
Password : test

(In reply to boute from comment #4)

Test site :
https://evasoft.fr/eva/demo-social.cgi
User : firefox
Password : test

Sorry, I have no idea about how to reproduce the problem with this site.
Could you provide some detailed steps?
Thanks.

To reproduce the bug :

• login with the given credentials
• click on the link [Liste des usagers]
• use the firefox [Back] left arrow to redisplay the previous page

The cache is not used : form is submitted again to get a fresh response (see date/time displayed on top/right of the page)
The submit confirmation is not displayed

Notes :

• when you use the firefox [Forward] right arrow, the cache is used as expected

• at this point, both firefox letf and right arrows work as expected between those 2 pages
• most of the time, clicking on a new link and using the firefox left arrow causes the bug again, but sometimes not

I just found that the cache-control header in the response from https://evasoft.fr/eva/demo-social.cgi seems not right.

[Cache-Control: private; Max-age=604800]

According to spec, this should be private, max-age=604800.
Could you fix it and see if Firefox can work as excepted?

Thank you for the correction
I corrected the Cache-Control header and it works as expected
However, the bug is still present if no Cache-Control header is present
You may check this at address https://ux1.evasoft.fr/eva/demo-social.cgi

The most serious part of the bug is : The re-submit confirmation is not displayed
This is harmfull when the submited POST has a permanent action (new record in a database, send an email, ...)
It's unconvenient when the page returned requires heavy computation

We have many sites suffering from this change since firefox 95
We have thousands of users and many of theim switched to Chrome because of this new behaviour

I dont know if the reason is the same, but I cannot login to https://www.ovh.com/auth/ since firefox 95

(In reply to Alain Boute from comment #9)

Thank you for the correction
I corrected the Cache-Control header and it works as expected
However, the bug is still present if no Cache-Control header is present
You may check this at address https://ux1.evasoft.fr/eva/demo-social.cgi

This seems like can be fixed by adding Cache-Control header?

The most serious part of the bug is : The re-submit confirmation is not displayed
This is harmfull when the submited POST has a permanent action (new record in a database, send an email, ...)
It's unconvenient when the page returned requires heavy computation

We have many sites suffering from this change since firefox 95
We have thousands of users and many of theim switched to Chrome because of this new behaviour

I dont know if the reason is the same, but I cannot login to https://www.ovh.com/auth/ since firefox 95

Is this a different issue?
If yes, Could you help us by using mozregregression to find out the root cause?
Thanks.

It worked without Cache-Control header before firefox 95
I will check with mozregregression to find out the origin

Checked with mozregregression : if found one bug report
Bug 1746223 Move ScreenOrientation.lock to version 97 in changelog r=geckoview-reviewers,agi DONTBUILD

(In reply to Alain Boute from comment #12)

Checked with mozregregression : if found one bug report
Bug 1746223 Move ScreenOrientation.lock to version 97 in changelog r=geckoview-reviewers,agi DONTBUILD

It's unlikely that bug 1746223 caused this problem.
Could you check again? Thanks.

The Cache-Control header does not correct the bug but it appears less often
To reproduce the bug with Cache-Control header, use the test site https://evasoft.fr/eva/demo-social.cgi
User : firefox
Password : test

• login with the given credentials
• click on the link [Liste des usagers]
• click on the link [TEST Alain]
• use the firefox [Back] left arrow to redisplay the previous page (once or twice)

The cache is not used : form is submitted again to get a fresh response (see date/time displayed on top/right of the page)
The re-submit confirmation is not displayed

This bug is intermittent : mozregregression may not give a pertinent diagnosis

About Severity = S3

I suggest Severity = S2 because :

• no workaround is known (The Cache-Control header does not correct the bug)
• it's harmfull when the submited POST has a permanent action (new record in a database, send an email, ...)

Many sites are suffering from this change since firefox 95
Thousands of our users and switched to Chrome because of this new behaviour

Valentin, do you probably have an idea which recent change that could cause this?
Thanks.

I did a mozregression myself and it points to bug 1732358.

Set release status flags based on info from the regressing bug 1732358

(In reply to Valentin Gosu [:valentin] (he/him) from comment #17)

I did a mozregression myself and it points to bug 1732358.

Can you try running mozregression with the fission pref set to find a better range?

Running ./mach mozregression --pref "fission.autostart:true" -g 80 came up with the following range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c25899d7b631470b983650ee254177381a62eaad&tochange=33139800aca52aac192973fe24c9b74df7c87e00

It could be bug 1668357 but I haven't confirmed yet.

I've confirmed this is caused by https://hg.mozilla.org/integration/autoland/rev/1aa67f749387
Olli, can you take a look?

So with Fission the previous page doesn't enter bfcache.

...but even without bfcache we have an issue with cache key.
Of course in general one can't assume the cache contains any entries.

https://hg.mozilla.org/mozilla-central/rev/82197520e6a1