Tested with latest debug and optimized builds on Mac and Windows. This bug is much more reproduceable on Mac than on Windows, and more reproduceable on optimized builds than on debug builds. I recommend debugging it on the Mac. - Go to http://www.w3.org/Style/CSS/ - Click reload again and again ==> You end up getting the page displayed without one or several stylesheets. Of course, it's easier to spot when none of the sheets is loaded because the page shows as plain HTML but keep an eye and you will notice sooner or later that you can have some of the sheets loaded but not the others, especially when it displays the message at the top "(This page uses CSS style sheets)" because the class "hide" is missing. Another way that allowed to reproduce the problem systematically with an optimized build on the Mac is: - Go to http://mvideo.cjb.net/ - Click on "2000" then on "Feb" then on one of the dates ==> You can see that some of the texts are displayed with the nifty font and correctly centered while some other ones appear in Times and left-aligned. Assigned to attinasi because it may be a side-effect of bug 17309 (although I think I heard about sporadic problems with loading stylesheets a bit before the fix for bug 17309 was in). CC'd Necko people who may have a clue, or at least help Marc to set some breakpoints at the correct places.

Nominating for beta1. Failing to load the stylesheets is fairly bad.

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

Bug 24819 was PDT- because it was difficult to reproduce. This bugs shows that the problem is more common than originally thought, especially on the Mac.

Putting on PDT+ radar for beta1.

Looking at this one: first I have to duplicate it, then find out who is failing and why, then determine a fix. SWAG at fix data: 3/1/00 (will update as I get more info)

I have had no luck reproducing this bug yet. Pierre, when the problem shows up do you see anything on the console? There is a printout in CSSLoaderImpl::DidLoadStyle that should dump to stderr when there is an error loading the stylesheet: if (mDocument && NS_FAILED(aStatus)) { // still have doc, must have failed // Dump error message to console. char *url; aLoadData->mURL->GetSpec(&url); cerr << "CSSLoaderImpl::DidLoadStyle: Load of URL '" << url << "' failed. Error code: " << NS_ERROR_GET_CODE(aStatus) << "\n"; nsCRT::free(url); } URLKey key(aLoadData->mURL); Cleanup(key, aLoadData); } I am wondering if you see this, or if you can put an alert of some sort (or breakpoint) there and try it on the mac (I have no mac to test on). I'll keep trying to reproduce it.

I am unable to duplicate this on NT after several tedious hours of trying over various link-speeds. Could this be a platform-specific networking issue? I'll have to get some help on Mac or it will take me a lot longer as I have no Mac of my own... Any offers?

I can reproduce this easily on Linux (cvs build from today). I'm on a 56K line shared amongst 10 people (very slow).

Rick: Could this be a socket transport timeout issue? What's the timeout? Does anyone know what the error code is that occurs?

I'll work on it. I can easily reproduce the problem and I heard that Mark is out sick today.

Adjusting title of bug to indicate that this is a REload problem. Adding notation that this will become PDT- if not resolved by 3/3. We'll have to release note it.

I have a page on my local lan that does this quite often. It won't ever do it the first time I visit it, but after that first time, it happens most every time. I don't have to hit reload for the bug to occur, I'm just revisiting the page, so I'm thinking it doesn't have anything to do with reloading a page in particular, but rather loading a page that has been loaded once in the past. So perhaps it has something to do with the page being fetched from the server and the css being loaded from the memory cache. Also, the page contains many tables, so it may be caused by it taking so long to layout all the tables. Being that it's on a 10 mbs lan, I don't think it has anything to do with network speen either.

Some test cases, in case they can be of help: http://www.orakel.ntnu.no/~oyvindmo/csstest1.html http://www.orakel.ntnu.no/~oyvindmo/csstest2.html http://www.orakel.ntnu.no/~oyvindmo/csstest3.html http://www.orakel.ntnu.no/~oyvindmo/csstest4.html http://www.orakel.ntnu.no/~oyvindmo/csstest5.html The test cases are: 1) <link ...> to static CSS file 2) Embedded CSS in <style>...</style> 3) <link ...> to PHP generating CSS identical to case 1 4) <link ...> to PHP generating CSS with Last-Modified in the future 5) <link ...> to PHP generating CSS with a 3 second delay in the middle (The CSS is returned with Content-type text/css in all cases, by the way.)

how is the style sheet loaded? Pierre? do we load these URL's synchronously? What api are we using?

My own observation, after finally getting to run my test cases myself, is that the only case that gets the bug to manifest itself, is csstest1.html. Looking at case 1 and 3, the difference is in the HTTP headers that get sent with the style sheet. Here is the diff of how it looks when fetching the style sheets with HTTP/1.0: --- httplog-default.css Fri Mar 3 09:15:08 2000 +++ httplog-default.php3 Fri Mar 3 09:15:44 2000 Server: Apache/1.3.6 (Unix) PHP/3.0.8 -Last-Modified: Wed, 09 Feb 2000 14:06:46 GMT +Last-Modified: Wed, 09 Feb 2000 14:06:47 GMT Connection: close Content-Type: text/css -ETag: "36ae4c-52c-38a17476" -Accept-Ranges: bytes -Content-Length: 1324 -X-Pad: avoid browser bug I've tried reloading csstest3.html hundreds of times, but the bug doesn't appear there, it seems.

jar: this is not a RE-load problem, it is a page load problem. valeski: the nsHTMLContentSink calls mCSSLoader::LoadStyleLink() which calls CSSLoaderImpl::LoadSheet() which loads the style sheet synchronously by using NS_OpenURI() and a nsIUnicharInputStream.

Feels like a dupe of http://bugzilla.mozilla.org/show_bug.cgi?id=26297

After another hour of trying to dup this one I finally did get a single failure. The console had the following error message printed out: CSSLoaderImpl::DidLoadStyle: Load of URL 'http://www.w3.org/Style/map-ns.css' failed. Error code: 2 I cannot get it to happen again. Is anybody else seeing this error message when the problem occurs?

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

Transitioning to PDT-. This bug seems really hard to reproduce... and we have to get out the beta.

(adding myself to cc list) Just came to report this with our site actually and found it listed in the very first message. Some people seem to have a hard time duplicating this. However, this doesn't seem very sporratic at all. It happens absolutely every time at http://mvideo.cjb.net/ ... The main frame doesn't load the CSS. The frame with the navigational ".2000." doesn't load the CSS, nor do any of the navigational popups with months/weeks under it. They should all be centered, in different colors, and a different font. This happens absolutely every time, i'm using 2000030508 on Windows 98SE ...

I have some test perl cgi scripts at http://www.vortxweb.net/ccs-pg/my-cgi/toykar/chayka5.cgi There are 4 scripts. Submitting from one page initiates the next. The external stylesheets are loaded only on the first visit to the first page. Pages 2-4 get no styles, and reloading does not correct it. It happens every single time. I'm running Win98 build 2000030215.

I think I've found a link between the stylesheet loading problem and enabling the memory cache. I have a lot of documents using the same stylesheet. When memory cache is disabled (though prefs), stylesheets load fine. However, whenever I enable memory cache, stylesheets stop loading intermittently, specially for the longer pages. And once it stops loading, there is no way to load it with the other pages (using the same style sheet) as well. Disabling memory cache enables the style sheet again.

One word of warning - disabling memory cache and re-enabling it (both through the prefs dialog) crashes mozilla with a stack overflow error in nsTextFormatter::vsprintf_append (WinNT 4 SP 6a) - filing separate bug for this.

Confirming on 2000030508/win98se that disabling the Mem Cache allows style sheets to work properly. It appears that style sheets *do* work properly in a non-framed page whether or not the cache is enabled. But in a framed page they only seem to load when the mem cache is disabled. (also note, I do not get the crash you spoke of disabling/enabling mem cache)

Also wondering if this problem has anything to do with whatever fix was done for the problem of CSS pages double rendering, my bug 29366 (dupe of bug 17309), as I do not see that specific problem anymore ...

I confirm that the problem is related to the Mem Cache. Changed Component to Networking:Cache and reassigned to owner.

Cleared the Status Whiteboard to ask the PDT team to reconsider. Gordon: how bad would it be to ship with the Mem Cache turned off by default?

Jud asked me to look at this bug... Based on the fact that the problem is with frames pages, I'm making a WAG that more than one frame is using the same style sheet and is exposing a bug that occurs only when a URL that is being loaded into the cache is requested a second time *before* the first load completes. At one time, I was going to have the cache code coalesce such overlapping requests into a single network access, but after a Necko meeting in which we discussed the level of software complexity imposed by this feature, the team decided that, for now, the first request would access the cache and subsequent requests for the same URL would bypass the cache until the first request completed. The code in nsHTTPChannel::CheckCache() is responsible for enforcing this no-coalesce policy. In particular, the code that checks whether or not the cache entry is being updated may be at fault: http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHTTPChannel. cpp#772 Another even more likely culprit, in my mind, is the code in nsHTTPHandler::NewChannel() that attempts to coalesce requests for the same URL into the same channel. I worry about that because there are a bunch of nsHTTPChannel instance variables maintained by the HTTPChannel code and there are likely to be assumptions that the state is per-connection, not per-URL. I would try disabling this nsHTTPChannel-coalesce code and see if the bug goes away. Incidentally, one way to reproduce this problem without the complexity of frames might be to create an HTML page which has many copies of the same *large* image on it, but each with different WIDTH and/or HEIGHT attributes. (This will cause many requests for the same image URL - I haven't tried this myself.)

I'd like to clarify that this bug doesn't happen on just pages with frames. In the original test cases, none of the pages have frames. It seems to me that it has something to do with loading a large page where the stylesheet document is already in the memory cache. I can get the bug to occur on almost any such page. The page for which I see this almost everytime I load the page is where I have an index page with many anchored links into a second page. After the first access to the second page, each access from the index page to the second page causes this bug to occur. It has sensitive information on it, so I can't post it here, but I'll see if I can get a good test case built from it.

OK, I've got a test case that will allow me to reproduce this bug every time. The occurance of this bug seems to depend on when things are loaded, as I am able to reproduce on this particular testcase over my lan, and off of localhost, but not over the internet. To reproduce: 1) set up a web server on your local machine 2) download the testcase i'll be attaching to my next comment 3) gunzip and untar it where you can access it from your webserver on localhost 4) access css-test/index.html with mozilla, IE http://localhost/css-test/ 5) Click on one of the numbers to load the page with stylesheets 6) Click back 7) Click on a different number to load the page with stylesheets a second time Result: On step 7, the page will load without stylesheets Tested on a Pentium II 400 w/ 64 MB ram. Running Debian Woody and apache 1.3.9-11 (default debian config).

This URL may also produce the same results, depending on your line speed: http://ss-i.com/~dan/test. This URL works fine for me, but I think it's because of my slow connection. I also at times get a partial stylesheet. Only parts of the stylesheet elements are applied. I'll get a blue background only, or a blue background and white boxes, for example. This bug has also been reproduced on win32 2000030516.

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

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

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

I think bug 28297 is a duplicate of this one. Although that bug is about external JS files not loading and this one is about external CSS files not loading, the descriptions are otherwise very similar. Both problems involve external files sourced into the HTML page, both problems go away when the memory cache is disabled, both problems are hard to reproduce for some people but easy for others, and both problems have test cases that work consistently when someone is running a web server on the same workstation on which they are running Mozilla.

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

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

Putting on PDT- radar for beta1. No time to address for beta1.

Can we at least get external CSS style sheets and external JS files to NOT be cached for beta1? Also, can anyone explain why caching CSS or JS file should be any less reliable than caching HTML or image files? Should we turn off caching altogether for beta1?

This bug severely affects all of the netcenter sidebar customization pages (weather, news, etc). You get javascript errors up the yazoo, since it's looking for functions that are defined in external js files. It also makes customizing impossible since the files that don't load are necessary. To see this simply: 1. Open sidebar 2. Click on customize 3. Click on Favorites and add a News panel 4. Click on customize Results: you will get js errors and the list of news sources will not load. If it works the first time, simply repeat This problem goes away when you disable the memory cache. Yet again renominating, and changing the summary to include js files. cc:ing rginda

That bug seems to destroy layout of a lot of sites, all sites reusing external css/js for me in recent builds. I can't reproduce it with M14, though. That all is happening for me on win98 & a fast internet connection...

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

In an attempt to bypass the mem cache (for now) for css urls we'll try bypassing the cache. Can someone who can reproduce this please try the following change? Index: nsCSSLoader.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/style/src/nsCSSLoader.cpp,v retrieving revision 3.35 diff -u -r3.35 nsCSSLoader.cpp --- nsCSSLoader.cpp 2000/02/02 23:04:27 3.35 +++ nsCSSLoader.cpp 2000/03/08 01:25:27 @@ -1116,7 +1116,8 @@ nsCOMPtr<nsILoadGroup> loadGroup; mDocument->GetDocumentLoadGroup(getter_AddRefs(loadGroup)); - result = NS_NewStreamLoader(&loader, urlClone, aData, nsnull, loadGroup ); + result = NS_NewStreamLoader(&loader, urlClone, aData, nsnull, loadGroup , + nsnull, nsIChannel::FORCE_RELOAD); #ifdef NS_DEBUG mSyncCallback = PR_FALSE; #endif

Can someone have a look at bug 28490 ? I suspect that it might be a dup of this. In both cases, the problem disappears after disabling memory cache, and both are problems with CSS not being loaded / loaded partially.

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

Unless someone beats me to it, I'll try the fix proposed by valeski tomorrow (my build is broken right now).

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

Hmm... in my builds as of 3/06/2000 I can no longer reproduce this (I still can in M14). Looking through Bonsai, I didn't see any obvious reason why this would be fixed... warren made a huge checkin that touched caches, CSS, network code, the whole nine yards that was supposedly implementing thread-safe addref/release (b=21556). It was done to prevent crashes on SMP but I wonder... espescially since this was an itermitant, timing-sensitive crash. Either that or my debug builds can't reproduce it becasue of changed timing.

Ok, valenski's patch fixed M14. However, I can't reproduce anymore with or without it on the tip (as of 03/06). So the bug may have been fixed in passing by some other change... or it may just have been buried by some timing change.

This is dogfood gor QA automation. But we will try todays build.

Per desale -"Can not reproduce it with todays builds. Looks like it got fixed magically." Marking Verified.

I'm trying to understand what the status is on this one. puetzk said he couldn't reproduce this now, but is that with or without valeski's fix? Did the fix/hack go into the tree (to not cache stylesheets)?

I just downloaded 2000030808 / Win98 and this problem is in absolutely no way fixed. Everything at mvideo.cjb.net should be loading info from the linked CSS file, and nothing appears to be doing it. Once again, disabling the cache makes them load fine ... This is not fixed.

Reopening. sentinel: Can you try valeski's hack? Thanks,

^ = Stupid Non-Programmer Windows User. :) I could if someone told me what to do.

please try my above patch.

Like I said, I would if I knew how ... :) I'm not a programmer and I have no idea what to do with that snippet of code ...

I am no longer able to reproduce this problem on the tip (I don't have valenski's patch on my tip build). However, I am able to reproduce quite consistently on my M14 build. Applying valekski's hack to my M14_BRANCH build makes it impossible to reproduce this bug with it (ie, succesfull avoids the problem). I think some people are still able to reproduce this with tip builds, but I can't anymore. I have no idea why.

I can still reproduce this bug on my cvs build, but not on a downloaded nightly (2000030709). And now, after applying valeski's patch, I am no longer able to reproduce on my cvs build. I think it did the trick. But I think this only fixes half the problem. Are people still able to reproduce the javascript half of the problem?

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

This happens consistently for me on Linux nightly build 2000.03.08.09: a style sheet is only used when first loaded, not on reload, not on other pages referencing the same stylesheet. Bug 31031 is probably a dup of this one, it's about JS, and was filed today, so it's not fixed for JS either.

The same thing seems to happen with XUL. Here are comments from our 3rd party partner: "if you reload an xul file that calls a stylesheet, the browser refreshes only the xul file but not the css file containing the stylesheet. The problem occurs if the css file is called from a web server, but not if it's loaded locally"

zach: Can you try the build with the patch? To apply it, all you have to do put the patch in a file (e.g. foo) and do this: cd layout/html/style/src patch -c <foo make

Oops zack: Take out the -c in the patch line, above.

Sorry, I'm strictly a nightly build kind a guy.

Putting on PDT+ radar for beta1. Must fix by 03/10 to make beta train.

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

The bug could still easily be reproduced with the tip on the Mac. Valeski's patch fixed it so I got the approval and checked it in. I'm not closing the bug though, because the absence of cache for Stylesheets and JS files may hurt the performance (see bug 17309). Changed the title to "Memory Cache doesn't work for CSS and JS files". Set target to M15. Reduced the CC list. Cleared the Status Whiteboard. Added 'perf' keyword.

Removed 'beta1' keyword.

I'm not familiar with the code, but appears to me jud's fix only addresses css files, can someone confirm?

See bug 28297 for a description of the problems with JS files. I can't reproduce the bug described there with my.netscape.com. paulmac: could you try too?

If people are still having problems reproducing this error, it happens readily at http://www.w3cdom.com/front.html After the page loads, click the "WELCOME" menuitem. This attempts to reload the iframe to its inintial state. Instead, it reloads without the stylesheet. If the main page is then RELOADED, it loses the css and javascript files everytime. Disabling mem-cache fixes this. I'll try to make a simple test-case from this...

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

Assigning to Jud, since he has an idea for how to handle JS files.

I can still reproduce the problems from bug 28297 on 030914 builds by reloading http://my.netscape.com/setup_frameset.tmpl?services=weather&mn_yes=1 and http://www.zapogee.com/~myk/tc30.html These are both problems with js files reloading which go away with mem cache turned off. However, for whatever reason, I can't reproduce it on Jud's debug build. I think he should check it in, however, since the css patch seems to have worked. Remarking PDT+, because it was removed in error.

I'm going to do an optimized build and kick it off to paulmac to ensure that my fix works for js files (since I can't reproduce the problem on my machine) updated status to reflect expected check-in date If anyone is still having problems with css files on builds 3/9 or after please speak up.

running build 2000030913 in WinNT4.0... External CSS problem seems resolved, javascript problem is till there... To see: 1- make sure mem-cache is on... 2- go to http://w3cdom.com/lab/bugwatch.shtml 3- RELOAD page... External javascript fails and will not come back till restart of browser or mem-cache disable.

valeski just checked in workaround for js files, someone please verify with 3/10 builds, thanks removing pdt+ but leaving bug open and re-assigning to gordon

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

PDT would like this bug closed out and a new one opened please.

thanks jud, this worksforme now with the js testcases listed above. I'm going to leave this bug open, but remove the dogfood keyword so the PDT team won't bug us anymore :-)

2000031008 (NT4 128mb) External css and js now seem to work with cache enabled. (on my testcase at least..) You folks rock!

I confirm: the JS testcases above work in today's build. Marking Fixed.

Only a workaround has been checked in, so this bug shouldn't be marked fixed, in my opinion. Re-opening bug since the original problem still remains and will hopefully get fixed post-beta.

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

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

I think bug 32704 is just bad browser detection, nothing to do with caching, that I can see.. just plenty of .layers/.all code. bug 29929 - Cannot reproduce with or without cache set on or off. I increased amout of text in <dl> to 100 times what is at URL, and it will still not drop the stylesheet. I don't think either of these is an actual bug, much less a dupe of this one... (all testing done with build 2000032115, WinNT4, 128mb) FWIW, external .js and .css have been behaving fine (for me) since 3/10's "fix" (tested with nearly everyday's win-build since 3-10-2000)

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

When the actual fix is in we need to remember to go back and re-enable the caching in the CSSLoader (and in the JS counterpart too I assume).

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

Moving to M17 which is now considered part of beta2.

REassign. Putting in a big number since I think this is hard

Putting on [nsbeta2-] radar. Adding nsbeta3 keyword for performance work in PR3.

David has left netscape and davidm@netscape.com is an invalid email address. Assigning his five remaining bugs to gagan to find a new owner for them. Thanks

oops i didn't actually reassign to gagan last time. sorry for the spam

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

->neeti

This bug is still existing. I can reproduce it very easy with my local webserver.

neeti could you investigate this? Considering its effect in performance I am making this a nsbeta3+

See bug 46548 -- css and js files loaded multiple times. Possibly related.

From re-reading the comments I have the impression that this bug-report is a bundle of three related problems. FIRST, there is the CSS cache problem mentioned in the summary. This lead me and some authors of earlier comments to this bug. From my understanding, caching was disabled as a workaround for problem #2 (see below). Not caching stylesheets can lead to a very bad performance on sites working with large, global stylesheets that are included on every page. SECOND, there is a problem with stylesheet loading. It seems to be timing related and manifests itsself in broken page styles (the stylesheet is either not loaded completly or not loaded at all). This problem can be reproduced best when using a local web-server, but other comments indicate that it also happens on remote web-servers if there is a high bandwidth connection to the server. My own experience (local site with frames) is, that this problem (let's call it half-loaded style sheets) has a probability of 60%-80% - when the whole frameset is reloaded. I have not seen it with unframed pages but previous comments indicate that it also happens then, maybe just not that often. Half-loaded style sheets occur completly independent of how the memory cache is configured. I can reproduce it with all possible combinations of memory cache settings (ie 0kb & disabled / xKb & disabled / yKb & enabled). THIRD, there may or may not be a problem with javascript files. I have not checked this, but there are other bug reports (XUL related like #46129) which indicate, that this problem _also_ still exists. My conclusions are: --> Due to the independence of caching CSS and problem #2 (half loaded style sheets), someone should probably reenable the caching of external style sheets. --> Maybe it would be better to change the summary or break this bug up into separate ones, because problem #2 (half-loaded style sheets) is not even mentioned in the summary. --> The whiteboard should be updated. In the moment, it reads "workaround checked in, 5 days". What does it mean, when will this five day period end ?

changing whiteboard to remove the outdated info. the workaround was put in a few months ago and it was simply to force reloads on css and js files.

When this is fixed, I will need to reexamine our behaviour on all the nasty tests in the CSS ImportTest, especially the "infinite" ones: http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/

BTW, "Pragama: no-cache" and "Cache-Control: must-revalidate" seem to be always sent when fetching image.

nsbeta3- We are not going to be able to get to this. Maybe we should take this up for RTM if we think the performance needs to be fixed that badly. RTM marked so this doesn't get lost in the wilderness.

not going to happen for rtm

This is a pretty serious bug to slip. I guess the message to developers is "Netscape supports CSS, but don't really use it in a meaningful way."

Nominating for mozilla0.9.

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

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

#1 Gordon told me that memory cache is used for IMAP only, so then the summary is at least confusing. So was the first step to take it out the Memory cache to avoid further problems? #2 it seems that someone made a hack around, forced reload, but that brakes rfc 2116 compliance, but that doesn't seems to bother you, even after almost a year now! #3 this bug increases network traffic, so this hack around introduced an serious performance issue. #4 can you at least make a user_preference for the time being? This way we don't have to reload all that files over and over again! #5 do you have any idea what is causing the real problem behind this bug? If I whas editors then I would like to know why Mozilla and Netscape are taking so long to fix this problem! Almost a year now! Is that because Netscape = AOL? And that AOL get paid for increasing internet traffic? That would be a hell of a story, don't you think?

Adding Gerv to CC. Gerv, I think when the new newsgroups have been created, we should add a mozilla.conspiracy-theory group.

The men in black suits have been dispatched. The situation will be under control short...oops! Is this mic on?

Nominating it for nsbeta1 might produce results :-) JS and CSS files should be cacheable. Gerv

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

So, now it's confirmed, memory cache = disk cache, right? Why else did you dup that last bug?

Revising summary as this problem is not particular to the memory cache.

That makes it crystal clear

Sorry for the spam, just adding to CC list.

targetting for new cache landing.

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

I'm seeing the opposite problem, with the 4/4 Linux build. I have an html page that does <script src="file.js"></script>; I make a change to file.js and try to reload the html page, but the changes don't show up on reload or shift-reload. (I have my cache pref set to "compare every time", if that matters.) Clicking "Clear memory cache" and "clear disk cache", then restarting, doesn't help (so apparently it didn't actually clear anything). However, moving aside the directories Cache and NewCache in my profile directory did finally show me the new page.

clear memory/disk cache buttons are not hooked up to the new cache yet. CSS/JS caching have been re-enabled - see bug 73905 - and the problem of reload/shift-reload not working is a known problem, but i don't know if a bug has been opened for this yet... would you mind opening a bug for this? thanks!

The Clear cache buttons in the cache preference panel now work, and Darin tells me the reload/shit-reload problems were fixed with his recent landing. If there are new issues with CSS and JS reloads, we'll open new bugs. Marking FIXED.

Bug still shows on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010323. CSS and JS files are not cached at all. Do I need to reconfigure something? This is an example HTTP request: GET /v/css/standardMoz06.css HTTP/1.1 Cookie: SessionV=5ha66c3; StylesheetV=defaultStd,standardMoz06 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010323 Pragma: no-cache Cache-Control: no-cache Accept: */* Accept-Language: en Accept-Encoding: gzip,deflate,compress,identity Keep-Alive: 300 Connection: keep-alive

Ouch... Sorry! Didn't check release date vs. post date. Downloaded rv:0.9+ Gecko/20010506 and CONFIRMED bug is resolved for my application. Cache works as expected (If-Modified-Since, etc.). Load speed of pages increases dramatically on a (simulated) 56k line. Please mark as FIXED again. Sorry again, Mark

It's not my bug but I'm able to mark it fixed, so I do change it back to fixed :)

verified