The css loader should see if the file is coming from the network or the disk. If the later, we should not force the reload. Jud, will this be okay? You had to hack this workaround in, right?

pierre, this sort of sounds like what we were talking about today; however, I'm not exactly sure what dougt means by "force the reload". dougt, could you clarify? N.B. that hyatt is implementing caching in the nsCSSLoader for "chrome:" URLs; see bug 46129. Is this something different?

this is a perfect lesson in not checking in something for someone else :-). I checked in the hack to not cache css nor js. I have no clue what the actual bug was :-/; I did as I was told. I'm not sure if it matters whether it was disk or net based. The problems we were seeing were definately net urls, but I don't think we tested files.

Judson: what hack are you talking about? I'm the one who checked in something for someone else: see bug 29370 [Judson Valeski 2000-03-07 17:26] and [Pierre Saslawsky 2000-03-08 20:51]. Anyhow how can I tell if the file is coming from the disk? Get the protocol and check for "chrome" or "file"? Any other?

argggh. my fault. this thing bounced around so many times I thought I had checked in the workaround.

Chris: yes, these are different problems. In bug 46129, hyatt implements a caching of the stylesheets where the style structure is stored in the XUL cache indexed by its URL. The present bug is related to bug 29370 ("Memory Cache doesn't work for CSS and JS files"). There was a hack suggested by Jud (or maybe someone else) that I checked in and which forces the reload for stylesheet that are loaded asynchronously. I guess that if that hack were not in place, it would allow the stylesheet to be fetched from the Networking cache. Hyatt's fix comes before the hack above and represents an even more efficient method (in terms of speed, not memory...) to access stylesheets that are already loaded.

I can't reproduce bug 29370... Oh well, keeping in mind that hyatt is going to check in IsChromeURI() for bug 46129, the patch for the present bug is: Index: nsCSSLoader.cpp =================================================================== RCS file: /m/pub/mozilla/layout/html/style/src/nsCSSLoader.cpp,v retrieving revision 3.49 diff -r3.49 nsCSSLoader.cpp 1132a1133,1160 > static PRBool IsChromeURI(nsIURI* aURI) > { > nsresult rv; > nsXPIDLCString protocol; > rv = aURI->GetScheme(getter_Copies(protocol)); > if (NS_SUCCEEDED(rv)) { > if (PL_strcmp(protocol, "chrome") == 0) { > return PR_TRUE; > } > } > > return PR_FALSE; > } > > static PRBool IsFileURI(nsIURI* aURI) > { > nsresult rv; > nsXPIDLCString protocol; > rv = aURI->GetScheme(getter_Copies(protocol)); > if (NS_SUCCEEDED(rv)) { > if (PL_strcmp(protocol, "file") == 0) { > return PR_TRUE; > } > } > > return PR_FALSE; > } > 1191a1220,1222 > nsLoadFlags loadAttributes = (IsChromeURI(urlClone) || IsFileURI(urlClone)) ? > nsIChannel::LOAD_NORMAL : > nsIChannel::FORCE_RELOAD; 1193c1224 < nsnull, nsIChannel::FORCE_RELOAD); --- > nsnull, loadAttributes);

r=dougt.

Approving for nsbeta3

Fix checked in nsCSSLoader.cpp

Marking verified per last comments.