Closed Bug 751753 Opened 13 years ago Closed 13 years ago

Firefox 12 aggressively caching pages

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Version:
12 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 748647
Tracking Flags:
Tracking Status
firefox12 - ---
firefox13 - ---
firefox14 - ---

People

(Reporter: Matt_G, Assigned: mayhemer)

Details

Attachments

(3 files)

qa - utf-8 meta tag has no effect
115.99 KB, image/png
Details
Charles Session Log
1.24 MB, text/plain
Details
logs after pressing Login button on http://travel-my-way.com/
35.71 KB, application/zip
Details
We saw a spike of reports this week on the SUMO forums that Firefox 12 is caching pages needlessly You can see the full thread here: https://support.mozilla.org/en-US/questions/926043 Here is the original post: ------------------------------- After upgrading from Firefox 11 to 12 I'm having serious problems with Firefox over-caching pages. For example if you: Go to a URL where you can enter comments. If after comments are entered you are sent back to the same URL Firefox is showing the old page (without your new comments). You have to do a refresh to see the new page (with the new comment) Even if the page has PHP headers: header('Cache-Control: no-cache, no-store, must-revalidate'); header('Pragma: no-cache'); header('Expires: 0'); Firefox ignores this too. -------------------------------------- The only similar bugs I found date back to 2009 and 2010, so I don't think this is a duplicate. I ran a report and all of the UA's from users reporting to have this issue are 11 or above. The majority of them are on Firefox 12 and Windows. I have not seen a similar spike on reports of this issue in input. Filing this bug just to be safe.
Component: General → Networking: Cache
Product: Firefox → Core
QA Contact: general → networking.cache
Keywords: qawanted
Michal and Nick - any ideas?
The original poster from the thread provided this URL as an example: http://www.wallwritten.com/ I can reproduce it by adding items to the cart. There are times when the cart will not show the actual number of items until you hit refresh. I cannot reproduce it on amazon though, so wondering if it is an issue with the site. I've requested more examples from the users reporting this issue. I'll update this ticket if they provide more.
Correction. Was not the original poster, but another user reporting the issue.
Have a look at the browser cookie information (I used the Web Developer toolbar for this). On my websites having the issues, Firefox 12 is actually starting a new session on a header redirect (which would normally not happen until you close the browser). My error messages in the session were not appearing because the session was now not the same... Something to maybe look into
Same issue with some pages based on a Zend Framework like travel-my-way.com. Check out the user semc19 password 1234. After refreshing the page or without caching the page you see that the login finally worked. Did not happen in Firegox 11 and before.
I've been trying to reproduce this on other sites like wikis and forums I'm subscribed to, but I haven't been able to reproduce this problem. Our web dev/qa team is trying to produce a test case that can help us find a regression range.
I discovered by accident that the problem was not occurring on sites with a utf-8 content-type meta tag. I added the tag below to the head of a page that was previously affected, and it fixed the problem. <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> By the way, I still consider this a bug in Firefox.
Also, you can fix the problem client-side by setting Firefox's "Default Character Encoding" preference to "Unicode (UTF-8)".
(In reply to Jonathan Robson from comment #8) > Also, you can fix the problem client-side by setting Firefox's "Default > Character Encoding" preference to "Unicode (UTF-8)". Thanks Jonathan, can you test using the mozregression tool to see when this started happening for you? Specifically, we need to see if this is a regression in Firefox 12. http://harthur.github.com/mozregression/
Keywords: regressionwindow-wanted
Unfortunately, I don't really have time for that right now (sorry), but I can tell you that this problem definitely did NOT exist in Firefox 11.
Juan, can you investigate along the lines of comment 8, 9, 10?
(In reply to Jonathan Robson from comment #7) > I added the tag below to the head of a page > that was previously affected, and it fixed the problem. > > <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> I suspect that this may not entirely represent the problem - http://www.wallwritten.com does include the utf-8 meta tag in it's pages. The caching behavior is persistent and reproducible; when adding items to the shopping cart the cart item count does not increment.
Attached file Charles Session Log —
I was able to replicate the problem and confirm that Firefox isn't rendering the updated page as sent by the server. I used a proxy to inspect the HTTP requests going between Firefox and the server: http://cl.ly/0r2L0f0R3w39401n1m1D The attachment is the Charles Session log produced in the screencast. Note how the proxy is able to see that the server sends back an HTML file with an item count of 3, but Firefox (Nightly 15.0a1 (2012-05-01)) shows the cached HTML with an item count of 2.
Sorry, wrong link for the last comment. This link will let you view the screencast online: http://screencast.com/t/pnXaFKR6gt
I apologize if I implied that my solution would work in all cases. I was simply trying to say that it worked for me. Unfortunately, for confidentiality reasons, I cannot share the app with which I was having the problem, because it is an internal app that we use at my job. I posted here in the hopes that my discovery would help track down the cause of the problem.
I don't understand the reason for it, but the patch from bug #748647 fixes this too. Using the info in comment 5 to reproduce, I also did a bisect for good measure with the result being 88544:4b7d5b27dd5f just like #748647. I haven't been able to figure out a minimal test case, but given the cause it must be something to do with the Cache-Control: no-store header.
Thank you so much for this solution. The Content-Header <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> fixed it for me. But is it ok for "utf-8" to be case-sensitive? We had exactly the same header before with the only difference being the charset "UTF-8" upper-case and it worked only after changing to lower case.
Some users has reported that patch for bug 748647 fixes this bug as well. I have just landed that patch as https://hg.mozilla.org/mozilla-central/rev/20bed1f4d9a1, so it should get to the next nightly build. Please test it. Thanks!
BTW, it will be possible to find the next Nightly on Thursday at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
Back on the redirects starting a new session and caching the page, I found starting the session before the header also temporarily fixed the issues my sites were having. Before it was the other way around... eg. session_start(); header("Cache-Control: no-cache, must-revalidate");
Assignee: nobody → honzab.moz
we have the same problem, please look here: www.maxximer.de
This http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-05-10-03-05-17-mozilla-central/ nightly contains the fix. memorexxi, robilim, Theo, Jason, Jonathan or anyone experiencing this bug: please check whether the just above referred nightly build fixes this bug or not. Thanks!
question please: which one is for win 7 german 32bit on this site: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-05-10-03-05-17-mozilla-central/ i want to try whether it fixes the problem Thanks
Thanks Josh, i tried it with this nightly version and i think it fixed the problem on my site (maxximer.de). I could not find any failure with this version. The cart works properly, you can add things, remove things and change the number with no more problems...
Hi Honza, the nightly fixes the problem for me. I downloaded firefox-15.0a1.en-US.linux-x86_64.tar.bz2 from the link you provided and it fixed the problem in all 3 cases where i came across it, mostly Zend Framework. Thanks, good work!
Thanks everybody for testing. If this issue is still present then please open a new bug and CC me.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
here are some websites have this issue when you "add to cart" nothing shows in the cart unless you refresh the page or go to a different page. http://www.geekatronics.com (my business site) http://www.bladesandbelts.com http://www.groupsaleonline.com http://www.beautyallinone.com
The problem still exist, please have it fix as soon as possible. This issue have serious impact to our clients. please have it resolved as quick as possible!
Hi guys, this was found to be a duplicate of bug 748647 which has been fixed in Firefox 13. We are on track to release Firefox 13 on June 5th. If you can't wait until then, you can download the latest Beta to confirm it's fixed: ftp://ftp.mozilla.org/pub/firefox/releases/13.0b4/ Thanks.
I *think* we can remove qawanted and regressionwindow-wanted from this bug since it was fixed over on bug 748647.
Status: RESOLVED → VERIFIED
Keywords: qawanted, regressionwindow-wanted
I've just tried to install FF 13.0b4 but it doesn't fix this problem. I still have problems logging-in into any WordPress wp-admin and using any WordPress admin panel because pages and redirects won't correctly refresh. I also have problems with this page on bugzilla... after i logged-in the page still told me that I'm not logged, I had to reload it (F5) before write this comment!
Can we please take this discussion over to bug 748647?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #34) > Can we please take this discussion over to bug 748647? Please don't! All these comments, when verified, will lead to reopening this bug, since it may not be completely fixed by bug 748647. On the other hand, bug 748647 is narrowed to a well known issue and has been 100% fixed in its narrowed scope. No more work has to be done on that bug.
I've just tried using another pc with FF 12.0 (syncronized with the previous one... so with same cookies, history, etc.; same o.s. Win7), and the bug is not present. The only difference between the two FF installations is that in the bugged one I've installed, some days ago, an add-on called BetterCache (v1.29) that I've removed some minutes after installation. Before installing/uninstalling this add-on, I never had this bug.
Ehi I'm sorry, I manually fix it editing about:config and resetting the params browser.cache.check_doc_frequency and browser.cache.disk.capacity that was (I think) permanently changed by the BetterCache add-on. So I don't think that this really represent a bug... I'm sorry
(In reply to kalamun from comment #37) > So I don't think that this really represent a bug... I'm sorry Thanks.
Please try to get 13 launched before june 5th as most our users (and other shopping cart sites) use firefox and this is drastically hurting business. Thanks
(In reply to Joel R. from comment #39) > Please try to get 13 launched before june 5th as most our users (and other > shopping cart sites) use firefox and this is drastically hurting business. > > Thanks Sorry, but we follow a strict schedule for releases. Firefox 13 will be released on June 5th; no sooner, no later. Apologies for the inconvenience.
I asked on #748647 as well, but is there any chance of a 12.0.1? Both issues have a real non-trivial cost to business.
At this point a 12.0.1 is highly unlikely unless a critical security or stability issue is brought to our attention soon. This bug does not meet the criteria of a .point release on its own. If we did do a 12.0.1 there would be a chance this could ride along with it. However, as I said, I personally don't see that happening. Sorry but you'll just have to wait a couple weeks or ask your clients to use Firefox 13 Beta in the meantime.
Honestly that is unacceptable as our store and many other shopping cart platforms are affected by this and have no way of communicating with them when they enter our site to tell them this nor should we have to. This could be fixed in 2 days if you wanted instead of stalling. This has already been going on long enough and your going to drag it longer. Do you have any idea how much business is being lost by this issue with firefox? Or I guess firefox doesn't really care as customers may just look at this issue as a website issue and not firefox. This is completely bogus and we will make sure not just our customer know firefox is buggy and unstable but we will start posting this to all interent shoppers with examples like this.
Honza: can we think of any things that sites can use until this fix ships to workaround this problem? Will new content show if instead of redirecting to the same page, we first redirect to a different URI, then back? Or can sites do something like tack on a query string parameter, anchor tag, or anything else that will avoid the unwanted cache hit?
Just append some random parameter to each url, somethink like http://...?time=<unix epoch> or http:...?rand=<random number> I've seen some shopping site do this to avoid the bug.
(In reply to Theo Nolte from comment #45) > Just append some random parameter to each url, somethink like > http://...?time=<unix epoch> or http:...?rand=<random number> > I've seen some shopping site do this to avoid the bug. I recently tried this and it does not help. If you look at http://www.supportersplace.com/ you'll see that Firefox refreshes the page every time a link is clicked. What this means is the user messages that should be shown disappear because they get loaded once (before Firefox does a second redirect). Can you suggest any other workarounds for this behavior? Our site is seriously suffering because of this bug.
To all: My suggestion is to try to temporarily remove no-store header value from Cache-control: from POST responses like signing-in and adding to cart. Workaround may be to set expiration time to immediate that will force the client to refetch every time. I've reproduced the behavior from comment 5 and studied the produced logs for correct and incorrect behavior (current mozilla-central vs the patch for bug 748647 reverted). Michal, if you have time, check them please, they are attached. The issue is that when we get 302 Found, it has no-store. The flag for inhibit caching is propagated and HTTP-memory-only session is then used to search. And the entry for / is then found. In case of correct code we reload from net. I think it could potentially be a bug in memory cache device, but I am far from being sure about that.
Session created in one page is not present in the next page. This issue is present only in FF 12.0. This is a serious problem.
Is this still set to be released today? (In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #30) > Hi guys, this was found to be a duplicate of bug 748647 which has been fixed > in Firefox 13. We are on track to release Firefox 13 on June 5th. If you > can't wait until then, you can download the latest Beta to confirm it's > fixed: > > ftp://ftp.mozilla.org/pub/firefox/releases/13.0b4/ > > Thanks.
Yes. If you don't want to wait for the web pages to catch up, you can grab the builds now from ftp://ftp.mozilla.org/pub/firefox/releases/13.0/
Looks like this is still not fixed. Try the home page of http://zentomi.com (after the google authentication). We set Cache-Control:public, must-revalidate, max-age=0 and an ETag. In my experience neither FF12 nor FF13 will ever revalidate.
Can you please file a new bug explaining that issue and mark it as "depends on" bug 748647? Thanks.
(In reply to oliver from comment #51) > Looks like this is still not fixed. Try the home page of http://zentomi.com After I allow zentomi.com to store data for offline, I can see we are sending an ETag-conditioned request that gets a 304 response. FF13. I can see it in the web console and also in Wireshark. If this is otherwise, please file a new bug and CC me.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: