184304 - When memory cache is disabled, no-store pages are not displayed at all

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P5)

Description

[Tavis Ormandy]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

The real bug is that we're not rendering it.  We should not require the cache to
render a page.

Comment 2

[Gareth K.]

Confirmed - Day old trunk LINUX.

Comment 3

[Darin Fisher]

hmm... odd... by design, necko does not depend on the cache in order to download
stuff.  investigating...

Comment 4

[Darin Fisher]

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.)

Comment 5

[Tom Everingham]

*** Bug 184261 has been marked as a duplicate of this bug. ***

Comment 6

[calocybe]

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.)

Comment 7

[Constantine A. Murenin]

2 [e-mail]: 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

Comment 8

[calocybe]

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.

Comment 9

[Suresh]

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!

Comment 10

[Darin Fisher]

so perhaps this issue has somehow been fixed since moz 1.2.1?

suresh: what version did you test?

Comment 11

[Suresh]

darin: I tested using the latest trunk builds when I last tested (on 3/4/03).

Comment 12

[Constantine A. Murenin]

Have tested version 1.3 (win32) with line
'user_pref("browser.cache.memory.enable", false);' in prefs.js, and the bug
still exists. 

Comment 13

[Daniel Wang]

*** Bug 180447 has been marked as a duplicate of this bug. ***

Comment 14

[Daniel Wang]

*** Bug 175478 has been marked as a duplicate of this bug. ***

Comment 15

[Daniel de Wildt]

*** Bug 227083 has been marked as a duplicate of this bug. ***

Comment 16

[Rene Pronk]

*** Bug 234757 has been marked as a duplicate of this bug. ***

Comment 17

[Adam Hauner]

Dupes have OS as Windows XP and All -> All.

Comment 18

[Constantine A. Murenin]

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). 

Comment 19

[Daniel de Wildt]

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);

Comment 20

[Asa Dotzler [:asa]]

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.

Comment 21

[Luke Usherwood]

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. 

Comment 22

[Luke Usherwood]

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)

Comment 23

[Tavis Ormandy]

(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.

Comment 24

[Peter Weilbacher]

*** Bug 236682 has been marked as a duplicate of this bug. ***

Comment 25

[Bernard Alleysson]

I would like to be able to run Firefox with no memory cache, in order to avoid
problems introduced by bug 284716

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

> 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.

Comment 27

[cowbert]

this bug is still present in rv1.8 gecko/20051111 (firefox 1.5).

Comment 28

[Adam Guthrie]

*** Bug 287501 has been marked as a duplicate of this bug. ***

Comment 29

[Samuel Sidler (old account; do not CC)]

*** Bug 309351 has been marked as a duplicate of this bug. ***

Comment 30

[Ria Klaassen (not reading all bugmail)]

*** Bug 321190 has been marked as a duplicate of this bug. ***

Comment 31

[Mike Connor [:mconnor]]

This doesn't seem like a blocker, but the Gecko folks can decide.

Comment 32

[Darin Fisher]

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.

Comment 33

[Andrew Schultz]

*** Bug 323902 has been marked as a duplicate of this bug. ***

Comment 34

[Vladimir]

(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.

Comment 35

[Dave Townsend [:mossop]]

*** Bug 327489 has been marked as a duplicate of this bug. ***

Comment 36

[coolynx]

(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.

Comment 37

[Mike Shaver (:shaver emeritus)]

Agree with Darin in comment 32, not a blocker.

Comment 38

[Dan Yefimov]

As far as I can see, this bug is fixed at least for Firefox 1.5.0.2 build 20060419. May be it's time to mark this bug as fixed?

Comment 39

[dolphinling]

Not fixed in trunk nightly. Perhaps you're testing wrong?

Comment 40

[Dan Yefimov]

What Firefox branch did you test?  1.5, 2.0 or 3.0?

Comment 41

[scratch]

bug still exists in 1.5.0.3.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Comment 42

[John Carney]

This bug is definitely still present in FF 1.5.0.4. 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.

Comment 43

[Martijn Wargers (dead)]

*** Bug 250218 has been marked as a duplicate of this bug. ***

Comment 44

[Peter Weilbacher]

Attachment: Patch following comment 19

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 45

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 46

[Darin Fisher]

-> peter

Comment 47

[Darin Fisher]

fixed-on-trunk

Comment 48

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 49

[Darin Fisher]

OK, putting this on the FF2 beta2 list.

Comment 50

[:Gavin Sharp [email: [e-mail]]]

Peter, should I check this in on the branch?

Comment 51

[Peter Weilbacher]

Gavin, yes, thanks that would be great.

Comment 52

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 53

[Christian :Biesinger (don't email me, ping me on IRC)]

(I also checked in the bustage fix that was necessary due to the different CloseCacheEntry signature on branch)

Comment 54

[Ria Klaassen (not reading all bugmail)]

*** Bug 353471 has been marked as a duplicate of this bug. ***