Closed Bug 1064040 Opened 10 years ago Closed 10 years ago

Back navigation not working with Basic Authentication in Firefox ver. 32.0

Categories

(Core :: Networking: Cache, defect)

32 Branch
x86
Windows Server 2008
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 1000338

People

(Reporter: alessandro.pasta, Unassigned)

References

()

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 5.2; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140825202822 Steps to reproduce: Back navigation after a POST in an application with Basic Authentication. Actual results: The BACK doesn't work, only a blank page appears. Only with VERY small pages, it seems to keep the navigation history of just the last 1-2 pages. Apparently it seems a bug related to a new cache management in Firefox ver. 32. It didn't happen before. Expected results: The expected result is to get the previous page, just as in Firefox ver. 31 or lower.
Creating a testpage with basic authentication and post is difficult with my environment. Do you have a public url for testing or are you willing to do a regression range search which would require some work like installing a tool ?
Flags: needinfo?(alessandro.pasta)
Hi Matthias, I published a very simple test page on the public address http://95.110.161.29:42002/, user=test, pwd=bug. The Test.aspx page reproduces the bug in Firefox ver 32. Hereafter is the full code of the test page: <!doctype html> <html> <body> <h1> Bug in Firefox ver. 32 </h1> <p> In order to reproduce the bug, just do the following steps:<br /> type "1" in the text box and "Next page" button<br /> then type "2" in the text box and "Next page" button<br /> then type "3" in the text box and "Next page" button<br /> then type "4" in the text box and "Next page" button<br /> then type "5" in the text box and "Next page" button<br /> <br /> then try to use the BACK navigation button for 5 times, to retrieve the 5 previous pages...<br /> as a result, you will see that the navigation history is lost and an "Expired document" error is raised.<br /> <br /> Thanks for your help! </p> <form action="Test.aspx" method="post"> <input type="text" name="CTRL1"><br /> <input type="submit" value="Next page"> </form> </body> </html> Thank you, Alessandro
Severity: normal → major
Flags: needinfo?(alessandro.pasta)
OS: Windows Server 2003 → Windows Server 2008
Thank you very much for the excellent testcase ! No more inbounds to bisect Last good revision: 58c5a3427997 First bad revision: 8475dbade7b3 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=58c5a3427997tochange=8475dbade7b3 My guess is : jduell@mozilla.com Thu May 15 23:32:22 2014 +0000 d61ae091de9c Honza Bambas — Bug 913806 - turn HTTP cache v2 on by default, r=jduell
Status: UNCONFIRMED → NEW
Component: General → Networking: Cache
Ever confirmed: true
Keywords: regression
Flags: needinfo?(honzab.moz)
This is duplicate of bug 1000338 (has a patch). The bad thing happens in nsHttpChannel::OnCacheEntryCheck. I can see in the log we are set VALIDATE_NEVER flag since going back via bfcache, it means doValidation is set to false at a certain point. But later doValidation gets set again, and it can happen only in the "Check the authorization headers used to generate the cache entry" block ; checked in a debugger. This causes the load to fail later because of |!mCachedContentIsValid && mLoadFlags & LOAD_ONLY_FROM_CACHE| and NS_ERROR_DOCUMENT_NOT_CACHED error.
Depends on: 1000338
Flags: needinfo?(honzab.moz)
Excuse me, I would like to know which is the planning to solve this bug. Is anyone taking care of it? When is the patch planned to be released? Thanks.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Alessandro, the work to fix this is in bug 1000338. Once that lands on the development trunk and sticks, we will have a better idea of which release the fix will end up in.
You need to log in before you can comment on or make changes to this bug.