Closed Bug 184304 Opened 18 years ago Closed 14 years ago
When memory cache is disabled, no-store pages are not displayed at all
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 im not an expert in mozilla or HTTP, ive just reviewed the documents in regards to a characteristic in moz that i think should be reviewed... if mozilla's memory-cache is disabled by setting its size to 0 KB, it responds to the no-store cache-response-directive by not displaying the page at all, i assume this means that as mozilla is unable to keep the page in volatile storage it decides to simply not display the page at all. No error or status indication is given, the statubar simply displays "Done.". i think this is wrong, and not what was intended in rfc2616, and also not what a user would expect, a user might believe that there was an error in mozilla as no indication of what has happened is displayed, eg [ bug 182684 ]. rfc2616 says "'MUST NOT store' in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it." so mozillas behaviour is understandable, but surely having a user disable the memory cache means that mozilla isnt intentionally storing the data on a non-volatile medium (obviously the disk cache in this case), but has no other choice but to. If mozilla then removes it from the disk cache after use then i believe the directive has been observed. even if people with more experience than me disagree, surely an option to ignore no-store in a dialog when disabling memory cache or at least an error message would be nicer behaviour? Reproducible: Always Steps to Reproduce: 1. Disable memory cache by setting its size to 0KB 2. Fetch a webpage sent with the no-store cache-response-directive examples: http://www.cdbaby.com/ http://appdb.codeweavers.com/ 3. mozilla wont display it. Actual Results: Mozilla refuses to display the page as it has no volatile store to write to. Expected Results: Displayed the page, then removed it from cache or display an error. SSL pages still function. rfc2616 relevant section http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2 old cachefaq http://www.mozilla.org/docs/netlib/cachefaq.html
The real bug is that we're not rendering it. We should not require the cache to render a page.
Confirmed - Day old trunk LINUX.
hmm... odd... by design, necko does not depend on the cache in order to download stuff. investigating...
the problem is here: http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#704 we should just close the cache entry if an error occurs while trying to initialize it instead of bailing. i suspect this configuration has simply never been tested. (by the way, running w/ a zero sized memory cache is not a good idea.)
Severity: normal → trivial
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → mozilla1.4alpha
*** Bug 184261 has been marked as a duplicate of this bug. ***
Confirming for Mozilla 1.1 and later on WinNT4. However, I have a memory cache of 4MB, not 0 (disk cache 80MB). Two more example pages are http://www.dresden-stadtplan.de/ and http://www.dvbag.de/inhaf/default.asp . If someone could confirm this behaviour with a memory cache > 0, I'd recommend to change the severity to 'major'. (Honestly, this makes me going mad.)
2 email@example.com: try to see if 'user_pref("browser.cache.memory.enable", false);' does exists in your prefs.js. To know more -- follow the previous link about the duplicate of this bug, or this one http://bugzilla.mozilla.org/show_bug.cgi?id=184261#c5
You are right, the mem cache was disabled by this line. Can anybody tell me how this line came in there? I'm pretty sure I didn't write it. (And as I first noticed this with Mozilla 1.1 I probably didn't do this in the debug prefs.) Have set it to true now and the pages in question load fine, so please consider my previous posting trash.
You may have disabled memory/disk cache in pref panel (Edit | Pref | Debug | Networking). Even with memory cache disabled, I couldn't duplicate this bug. i.e http://www.cdbaby.com/ and http://appdb.codeweavers.com/ loads fine with all the images. Anyone else still seeing this issue? Thanks!
so perhaps this issue has somehow been fixed since moz 1.2.1? suresh: what version did you test?
Target Milestone: mozilla1.4alpha → Future
darin: I tested using the latest trunk builds when I last tested (on 3/4/03).
Have tested version 1.3 (win32) with line 'user_pref("browser.cache.memory.enable", false);' in prefs.js, and the bug still exists.
*** Bug 180447 has been marked as a duplicate of this bug. ***
*** Bug 175478 has been marked as a duplicate of this bug. ***
*** Bug 227083 has been marked as a duplicate of this bug. ***
*** Bug 234757 has been marked as a duplicate of this bug. ***
Dupes have OS as Windows XP and All -> All.
OS: Linux → All
Why the Severity is set to Trivial? This is no trivial, since by mistake (my case, see one of the duplicates (Bug 184261#c5); and not only my duplicate, most duplicates of this bug do not know what the problem is with) user cannot see some major web-sites anymore... Please, consider to mark it Major, and set the higher priority. Has anyone tested this on a different platform? I bet it is not PC-specific... Marking Hardware: All. This behaviour should be documented in the release notes (CC'ing asa and adding 'relnote' keyword).
Hardware: PC → All
1) Setting browser.cache.memory.capacity to zero is identical to setting browser.cache.memory.enable to false. (nsCacheProfilePrefObserver::MemoryCacheEnabled returns PR_FALSE if the capacity is zero otherwise it returns the enabled status.) 2) nsHttpChannel::InitCacheEntry will fail because it calls mCacheEntry->SetStoragePolicy(nsICache::STORE_IN_MEMORY) which will fail because the memory cache is disabled. As mentioned in comment 4: 3) nsHttpChannel::ProcessNormal will fail because it calls nsHttpChannel::InitCacheEntry. I tried Darin's proposal to disable the cache and it seems that this works fine. I replaced the marked line in http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp&rev=1.191&mark=762#743 with if (NS_FAILED(rv)) CloseCacheEntry(rv);
We don't even have primary UI to set memory cache that I know of. If you're hacking your prefs file with a text editor or about:config, you're on your own. This is not release note worthy and might even be worth wontfixing.
I see this is a long standing bug, which has been assigned low priority. I would like to add my 2 cents, that disabling the memory cache for me has enhanced performance significantly. You see, I regularly run mathematical simulations which consume >1GB of RAM. Under these circumstances other processes quickly get swapped out to the page file, which I presume includes mozilla and its "in memory" cache. (or is the memory cache somehow flagged as non-swappable memory?) The delays when using Mozilla after it has "swapped out" are reduced with the memory cache disabled. (Note: a purely subjective comparison) With the memory cache disabled, mozilla consumes much less Virtual Memory (usually around 20MB, as opposed to 30-60MB), which probably helps a lot too. However, I have quickly run into these problems where a page doesn't display. My example is any page generated by 'Tiki': sourceforge.net/projects/tikiwiki/ Could the meaning of the memory-cache preference could be changed to "prefer disk", so that when the storage policy dictates the page be held in memory, it can be. The memory can be released as soon as such a page is closed.
Interestingly, if you set both types of cache off: browser.cache.disk.enable = false browser.cache.memory.enable = false Then the various "problem pages" no longer have any problems! So this bug must only occur when disk=true and memory=false. (In Mozilla v1.8 beta 1)
(In reply to comment #20) > We don't even have primary UI to set memory cache that I know of. If you're > hacking your prefs file with a text editor or about:config, you're on your own. You're right about that, I was using galeon when I reported this bug, which did have a UI to set the cache size (I don't know if it still does), I didnt check if mozilla had a way to set it.
*** Bug 236682 has been marked as a duplicate of this bug. ***
Summary: no-store cache-response-directive possibly incomplete implementation → When memory cache is disabled, no-store pages are not displayed at all
I would like to be able to run Firefox with no memory cache, in order to avoid problems introduced by bug 284716
> I would like to be able to run Firefox with no memory cache that's a really bad idea, fwiw. stuff like file|save page as and view source will probably always retransmit the data, at least for https:// urls.
this bug is still present in rv1.8 gecko/20051111 (firefox 1.5).
*** Bug 287501 has been marked as a duplicate of this bug. ***
*** Bug 309351 has been marked as a duplicate of this bug. ***
*** Bug 321190 has been marked as a duplicate of this bug. ***
This doesn't seem like a blocker, but the Gecko folks can decide.
Flags: blocking-firefox2? → blocking1.8.1?
I don't think this should block the FF 2 release. Disabling the memory cache is an unsupported mode of operation. You can set its size to something small, but it shouldn't be set to zero size. Target milestone is future for a reason. Patches welcome, but I don't plan on fixing this anytime soon.
*** Bug 323902 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > I don't think this should block the FF 2 release. Disabling the memory cache > is an unsupported mode of operation. You can set its size to something small, > but it shouldn't be set to zero size. > > Target milestone is future for a reason. Patches welcome, but I don't plan on > fixing this anytime soon. > How the size of memory cache can be set? I do not see the corresponding parameter.
*** Bug 327489 has been marked as a duplicate of this bug. ***
(In reply to comment #21) > I see this is a long standing bug, which has been assigned low priority. > > I would like to add my 2 cents, that disabling the memory cache for me has > enhanced performance significantly. Totally agree with this comment. Since FF1.5 release I was suffering huge memory problems, swapping etc. and tried everything I could find about tweaking this poor bastard. Then I found a solution - browser.cache.memory.enable = false. I was happy for some time but I was wrong because some pages did not open at all. And my luck was gone again. IMHO until most of the memory problems are solved this setting would be the solution for users who has swapping problems (every other user?). At least I have not seen any other working solution like this one.
Agree with Darin in comment 32, not a blocker.
Flags: blocking1.8.1? → blocking1.8.1-
As far as I can see, this bug is fixed at least for Firefox 220.127.116.11 build 20060419. May be it's time to mark this bug as fixed?
Not fixed in trunk nightly. Perhaps you're testing wrong?
What Firefox branch did you test? 1.5, 2.0 or 3.0?
bug still exists in 18.104.22.168. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060426 Firefox/126.96.36.199
This bug is definitely still present in FF 188.8.131.52. I spent a few hours hunting through my website source for an obscure bug affecting some FF users and it turned out to be this. The workaround was simple - simply take "no-store" out of my cache-control headers, but I think it's high time that this bug be ratcheted up the priority list. In the course of researching this issue I found a number of "tips & tricks" sites that recommend disabling the memory cache as a matter of course. There are also numerous sites that use "no-store". I don't understand what's the problem with fixing this. People have gone to the trouble of identifying the relevant section of code and fixed it. Surely it's just a matter of pushing it into the next release cycle???? Why hasn't it been done already??? Seems like a no-brainer to me.
*** Bug 250218 has been marked as a duplicate of this bug. ***
There is probably a reason why Daniel did not make his fix from comment 19 into a patch to get reviews, but I am trying it anyway. It still seems to fix it for me (tested with trunk on OS/2) without any side-effects that I could see.
Comment on attachment 227286 [details] [diff] [review] Patch following comment 19 could you add -p to your diff options for future patches? thanks! imo it would also be good to get this fixed for the 1.8.0 and 1.8 branches
Attachment #227286 - Flags: review?(cbiesinger) → review+
Assignee: nobody → mozilla
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 227286 [details] [diff] [review] Patch following comment 19 requesting branch approval. this should be a pretty safe patch, it just makes failure to initialize the cache entry not fatal.
Attachment #227286 - Flags: approval1.8.1?
OK, putting this on the FF2 beta2 list.
Flags: blocking1.8.1- → blocking1.8.1+
Target Milestone: Future → mozilla1.8.1beta2
Whiteboard: [checkin needed (1.8 branch)]
Peter, should I check this in on the branch?
Gavin, yes, thanks that would be great.
I checked this in on MOZILLA_1_8_BRANCH since I was also doing some other checkins Checking in netwerk/protocol/http/src/nsHttpChannel.cpp; /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v <-- nsHttpChannel.cpp new revision: 1.256.2.19; previous revision: 1.256.2.18 done
(I also checked in the bustage fix that was necessary due to the different CloseCacheEntry signature on branch)
*** Bug 353471 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.