Closed Bug 40449 Opened 25 years ago Closed 23 years ago

Cache does not store latest value of pages

Categories

(Core :: Networking: Cache, defect, P3)

Product:
Core
Component:
Networking: Cache
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: gordon)

References

(
URL
)

Details

(Whiteboard: [dogfood-][nsbeta2-][ETA 07/31])

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m16) Gecko/20000518 BuildID: 2000051820 The cache is not storing the latest copy of pages viewed. Instead the copy you first viewed in that session is stored, no matter how many subsequent refreshes you have done. Reproducible: Always Steps to Reproduce: 1. Start a new mozilla session 2. Open a frequently updated web page (e.g. tinderbox) 3. Note the contents of the page, wait long enough for the page to be updated. 4. After a little while manually refresh the page 5. Broswe somewhere else on the web 6. Reenter the frequently updated page (e.g. from bookmark) Actual Results: At 2 the page is correctly displayed. (In my example tinderbox at 02:18 EST) At 4 the page is updated (e.g. tinderbox from 03:xx) 5 is fine At 6 the page is retrieved from cache with the data of 02:18, rather than the later 03:xx I had viewed previously. This cache data is out of date. Expected Results: Up to 5 as actual results At 6 the latest copy of the web page you have viewed should be retrieved from the cache. I have seen this with this build on both tinderbox and slashdot. I suspect other frequently updated sites (e.g. BBC news) are also affected. I haven't (yet?) investigated what effect any page expiry settings are having on this.
Confirmed. I do not see any bugs currently describing this behavior, but it's there. What I've noticed is that when I'm at Slashdot, viewing an article, and then I hit the Back button, I get an old version of the page. Hitting reload brings up the new page.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Back should get you an old page since we don't do validations on back or forward. What is your preference for cache validation set to ( once per session/ every time/ never)?
Preferences for cache validation are whatever the default setting is. Now, as for the problem... I was on the Slashdot main page. It was new and up-to-date. I clicked into an article I clicked back I got the Slashdot main page from about a day ago! I have not left mozilla running for more than a day, and I upgrade to the latest nightly build every morning. No matter how you look at it, that ain't right! ;-)
Well a day is a bit long;) I can't reproduce so I am guessing that your disk cache files are corrupt( or perhaps you have an old version of the product which doesn't set directory permissions properly). Try throwing the cache directory away and see if that clears up the problem. BTW the ui for clearing the cache was busted last time I checked.
Surely the preferences on my cache are irrelevant (they are the default anyway - I can't access that prefs panel!). The bug is not that a cached version of the page is displayed; but that the cached version is not the last version you browsed. The cache should always contain the latest copy you viewed of any particular page - not the earliest!
*** Bug 41071 has been marked as a duplicate of this bug. ***
I am seeing this same behavior in today's newest build 2000060415 Actually, I searched out this bug to make sure I wouldn't enter a duplicate. This is exactly what I am seeing. I have a simple html page that I loaded, kept the browser running, added a link to the page, reloaded and successfully got the new link listed, clicked the link and then hit back. I went back to the old version of the page before the link was there. After I shut down the browser and restarted it, I went back to that page. It loaded the first time with all the links showing and going back and forth kept those links. I don't think the issue is "when should the browser do validations". On refresh, a new copy of the page should be put into cache and the older one discarded. You won't have to worry about validating the page when hitting the "back" button because you will know that you have the most recent page you viewed. If, after that, you feel you are not viewing up to date info, then you manually do a refresh to get that info. That is how IE, Opera, and all Netscape browsers have worked in the past, present, and should work like the future. BTW, like Bruce, I also download nightly builds pretty much every day and delete everything from the older version each time including the bin, users50 directory and the mozregistry.dat. So every time I run the browser, it is totally a fresh copy in every way. No cache corruption here. jake
I cannot reproduce the problem. I performed the steps 1 through 6 mentioned below for http://www.slashdot.org and tinderbox. For step 6, the latest value of the webpage I have viewed should be retrieved from the cache. Neeti
Reassigning to neeti
Assignee: gordon → neeti
Resolving this bug as WORKFORME. I have tried this many times by performing steps 1 through 6. for http://www.slashdot.org and tinderbox. For step 6, the latest value of the webpage I have viewed is retrieved from the cache. Neeti
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
With 200062220, I am still seeing this. At first, I thought the bug was slightly different than this bug so I filed bug 43605 Upon further investigation, I am thinking that perhaps I should re-open this bug instead? Either way, one of these 2 bugs is probably a dupe of the other. I am seeing this: When I go to http://bugzilla.mozilla.org and click on the "Bugs Submitted today" link, I get a list of bugs. Fine. Now come back a couple hours later. Click on the "Bugs Submitted today" link again and then click into one of the bugs. When you click Back, the list of Today's Bugs is the earlier version (from a couple of hours ago). Hit reload and the new page comes up. The easiest way to see this is to count the number of "UNCONFIRMED" bugs at the top, reload, and then count again. I just did this right now and it was 6 at first. I pressed reload and it was 10. If I click a bug and then click back again, bingo! It's back to 6! I can do this over and over again. The only way I know a page is current is by hitting reload.
I have started seeing this bug again too with M16 (build ID 2000061311) Again tinderbox or slashdot demonstrate it. It doesn't happen all the time now as it used to, but I notice it at least once or twice a day.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 43605 has been marked as a duplicate of this bug. ***
Nominating for nsbeta2. This makes it very difficult to use bugzilla, since I often end up looking at out-of-date copies of bugs. (I'm not nominating for dogfood because I suspect it won't get a + for dogfood because there is a workaround - hit reload every time.)
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
*** Bug 44107 has been marked as a duplicate of this bug. ***
see also http://bugzilla.mozilla.org/show_bug.cgi?id=38244 and http://bugzilla.mozilla.org/show_bug.cgi?id=44107. adding dogfood keyword because 44107 had it.
Keywords: dogfood
Putting on [dogfood+] radar.
Whiteboard: [nsbeta2+] → [dogfood+][nsbeta2+]
I've been seeing this bug persistantly for the past couple of days (fresh nightlies each time). Current build ID is 2000062921. I'll go to Slashdot, view, then continue on with my business. If I come back to Slashdot (by typing the url into the location bar) I'll get the old page. If I hit the reload button, it'll grab a fresh page, and I'll get the new content displayed. If, after that, I type the SAME url into the location bar (I usually just click the location bar and hit enter) Mozilla will display the OLD page once more. I have my cache settings set to "Every time". A couple of times I've blown away my $HOME/.mozilla directory completely to remove the cache, and the behavior will return as soon as the page gets into the cache.
*** Bug 44300 has been marked as a duplicate of this bug. ***
I had a few other observations in bug 44300. My cache was set to /usr/local/netscape/cache, which was a shared cache with NS4. I cleared the disk and memory caches from Mozilla in case the disk cache was full. The disk cache was cleared, I was still seeing the same problem. I had 'use memory cache' set to 'on' in Preferences|Debug, so I think this may be a memory cache problem. Now this might be a red herring but what I suspect is happening is this: I visit page on date A. Page is stored in mem cache and disk cache. I visit page on date B. Page is loaded. Disk cache version is loaded into mem cache. New version is not cached because there is already a version in memory cache. When I go back to page, (incorrect) memory cache version is loaded. I clear disk and memory caches. Disk cache is cleared, but memory cache is not. When I go back to page, (incorrect) memory cache version is loaded.
Status: REOPENED → ASSIGNED
Sorry, ignore that last bit. I just saw this problem reappear. I cleared both disk and memory caches, and that seemed to fix it. When I went back the current version of the page was loaded.
Blocks: 43828
Ok. I'm checkin in the fix for the multimixed converter (##1 ....)
Make sure you don't reverse the polarity on the flux capacitors.
Is there any traction on this. This bug makes using mozilla in Bugzilla nearly impossible.
Because people are not using bugzilla because of this bug, other serious regressions in forms are slipping in. See bug 45396. We need people to use bugzilla to catch regressions in forms and form submission, which are a key part of the browser. Is there an ETA for this bug?
I have a fix in hand. Waiting for a code review. Neeti
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I'm still getting cached pages when I visit bugs in bugzilla 071408 win32 build.
Asa, could you specify the sequence of steps you did to reproduce this bug. Thanks, Neeti
most recent occurrence I opened win32 071708 mozilla build in NT and launched mail from the tasks menu. I read a bugzilla email and clicked on the link in the email that opened the bug report in the browser. I commented and submitted a status change on a bug. About an hour later I read another bug email that linked to the same bug. When I clicked on the link in the mail it took me to the bug but did not reflect the changes I had recently made. I hit the reload button and was able to see my changes.
I've been asked to verify this bug in tever's abscense, however from the previous comments it appears that this bug is still active. Reopening bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This bug is about the Cache not storing the latest value of pages for example if you do 1. Start a new mozilla session 2. Open a frequently updated web page (e.g. tinderbox) 3. Note the contents of the page, wait long enough for the page to be updated. 4. After a little while manually refresh the page 5. Broswe somewhere else on the web 6. Reenter the frequently updated page (e.g. from bookmark) Actual results - You should see the page you last viewed, i.e the page viewed at step 4, and not the page at step 2. Jan, could you please perform the above steps to verify this bug? --------------- Asa, If you had you Cache setting set to "Once per session" instead of "Everytime I view the page", the page is validated only once per session, and the rest of the time, it gets it from the cache. Either way, this is a different issue, from the bug mentioned here. Neeti
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
verified: Linux 2000072020 WinNT 2000072108 Mac OS8.6 2000072108
Status: RESOLVED → VERIFIED
Redhat Linux 6.1 July 21. I go to Slashdot. I'm logged in automatically due to the cookie set. I click on an article. I click the back button. The page that comes up is from June 28, and I am not logged in. When I click Reload, the correct page comes up.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
tever, Could you check this out on Redhat Linux 6.1, by going to slashdot.org? Thanks, Neeti
yeah, I'm checking it out with the back button and bookmarks. Your series of steps with tinderbox worked for me on rh6.1
I have not cleared my cache any time recently, but I wouldn't think that it would matter, correct? Even if there's something in the cache, it should be overwritten with the new version, right? The above steps have the same result 100% of the time. (Old page from Jun 28)
I have been trying to reproduce this bug for the last 3 days with the www.slashdot.org site, and everytime I hit the backbutton, I see the page I last viewed and not an old version. Neeti
I am running this on Redhat Linux 6.1 Neeti
I may have seen this happen once on jgrm's machine. It was very soon after the slashdot page was updated. Will re-check this morning.
It still does this on my system (RHat 6.1) with 200072420 Every time.
confirmed that what I saw was caused by preference setting "Compare page in cache .." once per session. My mistake.
Is anyone else besides wdormann seeing this?
Whiteboard: [dogfood+][nsbeta2+] → [dogfood+][nsbeta2+][ETA 07/26]
I've seen it recently. But I just tested the tinderbox example on comm build 2000072508 with a clean profile and it worksforme. the first time i went to the page it said 19:23, later I hit reload. Then it said 19:27. I left the page (clicked on a bookmark), then when I hit back the tinderbox page said 19:27.
Steve, wdormann says "Redhat Linux 6.1 July 21. I go to Slashdot. I'm logged in automatically due to the cookie set. I click on an article. I click the back button. The page that comes up is from June 28, and I am not logged in. When I click Reload, the correct page comes up." Does this ring a bell. Have you seen any bugs like this? Thanks, Neeti
It sure does ring a bell. Take a look at bug 45468.
Also take a look at bug 46514
Updating ETA for 7/28 for a workaround. gagan looking at this with neeti.
Whiteboard: [dogfood+][nsbeta2+][ETA 07/26] → [dogfood+][nsbeta2+][ETA 07/28]
Just a note about tinderbox. There are two different URLs: http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey&nocrap=1 Mozilla seems to store two distinct cached copies for these URLs, and displays the respective cached page whenever you enter its URL later in the session. I don't know if this is intentional, but it seems a bit odd to me. Going to these URLs with 4.x always gives me a fresh page from the server, no matter whether or not I visited tinderbox before in that session. I mention this here because this is another situation where you get a page content that is older than expected. (PC/Linux 2000072408 mozilla build)
*** Bug 24679 has been marked as a duplicate of this bug. ***
I think Andreas Franke's latest comments describe what is now filed as bug 46825, which is different from this bug.
Per todays Beta2 bug review...will put in hack to get us good for PR2. Will do perm fix in PR3.
Our first few attempts to fix have failed, and we will try to get it resolved by 7/31
Whiteboard: [dogfood+][nsbeta2+][ETA 07/28] → [dogfood+][nsbeta2+][ETA 07/31]
*** Bug 43946 has been marked as a duplicate of this bug. ***
Spoke with gagan, fix is too risky for PR2. Will release note that this may happen with pages that have redirects. Setting to [dogfood-][nsbeta2-]
Keywords: relnote2
Whiteboard: [dogfood+][nsbeta2+][ETA 07/31] → [dogfood-][nsbeta2-][ETA 07/31]
Blocks: 30852
Checked in a fix on the branch. Will checkin the changes on the tip once it reopens. Neeti
Checked in a fix on trunk. I am not yet marking this fixed, because we want to revisit this bug and look for a more robust fix, than the hack I just put in. Tever, Could you verify this bug on the branch? Thanks, Neeti
neeti, I will mark this fixed to get tested with tomorrows branch builds. Thats when tever can test. I will reopen for you after that.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
*** Bug 47264 has been marked as a duplicate of this bug. ***
*** Bug 44226 has been marked as a duplicate of this bug. ***
WFM now Redhat 6.1
verified branch - Linux 2000080304 Win NT 2000080304 Mac OS8.6 2000080304
Status: RESOLVED → VERIFIED
fyi, bug 44226 has a good testcase for this
*** Bug 48370 has been marked as a duplicate of this bug. ***
WE are changing the way this is getting fixed. WE need to reopen the bug.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Neeti checked in fix 8/30 1pm
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
verif: winNT 2000090708 Mac OS8.6 2000090704 Linux rh6.0 2000090708
I've been seeing this for the past week or so at http://www.slashdot.org WinMe. 2001042704
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
-->gordon
-->cache
Assignee: neeti → gordon
Status: REOPENED → NEW
wdormann, this bug was for the old cache, which has been removed and completely replaced by a new cache. If you are noticing problems with the new cache, please create a new bug with a complete description of the problem. It will be easier for us to track and debug if we don't have to sift through observations of the old cache. I'm marking this bug as fixed, but we'll investigate any new bug you open. Thanks.
marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
-relnote - fixed and not in current relnotes:
Keywords: relnote2
Hi, Maybe the problem is slightly diffrent, but for a moment, One sesion in which the computer had to be rebooted again, The browser just didn't seem to remember the images he just downloaded. Since I work in windows 95 during reboot, scandisc fixed two Failures in the directory structure, (which I saved. If you want to I can send you this unfixed directory thing) Right now the problem is solved by scandisc but maybe you have a serious bug bwefore you bring Mozilla in a definitive version on the market. Start-up is 3 times as fast as Netscape 6.2 (20 seconds vs 60 seconds) Mail allert in mailer is great! Keep up the good work!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It's not clear this has anything to do with the original bug, or that it's a bug at all. There are many factors that determine whether the images that may have been in the cache would get reused. If this problem persists for you, I would recommend a new bug. Marking FIXED.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.