Closed Bug 29370 Opened 25 years ago Closed 23 years ago

Cache doesn't work for CSS and JS files

Categories

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

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: pierre, Assigned: gordon)

References

(
URL
)

Details

(4 keywords, Whiteboard: [nsbeta2-][nsbeta3-] [rtm-] hit during nsbeta2 standards compliance testing)

Attachments

(1 file)

testcase
2.15 KB, application/x-gtar
Details 
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.
Keywords: beta1
Status: NEW → ASSIGNED
*** 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.
Whiteboard: [PDT+]
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)
Whiteboard: [PDT+] → [PDT+] SWAG fix date: 3/1
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.
Whiteboard: [PDT+] SWAG fix date: 3/1 → [PDT+] SWAG fix date: 3/1 w/b minus on 3/3
Summary: Stylesheets are not always loaded → Stylesheets are not always RE-loaded
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.
Summary: Stylesheets are not always RE-loaded → Stylesheets are not always loaded
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.
Whiteboard: [PDT+] SWAG fix date: 3/1 w/b minus on 3/3 → [PDT-] SWAG fix date: 3/1
(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.
Assignee: attinasi → gordon
Status: ASSIGNED → NEW
Component: Style System → Networking: Cache
QA Contact: chrisd → tever
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?
Whiteboard: [PDT-] SWAG fix date: 3/1
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).
Attached file testcase — 

    
    

    
  
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.
Whiteboard: [PDT-]

    
    

    
  
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
Summary: Stylesheets are not always loaded → Stylesheets and JS files are not always loaded
Whiteboard: [PDT-]

    
    

    
  
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.


    
  
Blocks: 11349

    
    

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

    
    

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

Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

    
  
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,
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
^ = 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?


Summary: Stylesheets and JS files are not always loaded → External stylesheets and JS files are not always loaded

    
    

    
  
*** 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.
Summary: External stylesheets and JS files are not always loaded → Stylesheets and JS files are not always loaded

    
    

    
  
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.
Whiteboard: [PDT+] w/b minux on 03/10

    
    

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

    
  
Target Milestone: M14

    
    

    
  
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.

Blocks: 17309
Keywords: perf
Summary: Stylesheets and JS files are not always loaded → Memory Cache doesn't work for CSS and JS files
Whiteboard: [PDT+] w/b minux on 03/10
Target Milestone: M14 → M15

    
    

    
  
Removed 'beta1' keyword.

Keywords: beta1

    
    

    
  
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.

Assignee: gordon → valeski
Status: REOPENED → NEW

    
    

    
  
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.

Whiteboard: [PDT+]

    
    

    
  
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.
Whiteboard: [PDT+] → [PDT+] will check in 3/10 if fix works on optimized

    
    

    
  
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
Assignee: valeski → gordon
Whiteboard: [PDT+] will check in 3/10 if fix works on optimized → workaround checked in

    
    

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

    
    

    
  
PDT would like this bug closed out and a new one opened please.
Summary: Memory Cache doesn't work for CSS and JS files → [PDT-]Memory Cache doesn't work for CSS and JS files

    
    

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

Keywords: dogfood
Summary: [PDT-]Memory Cache doesn't work for CSS and JS files → Memory Cache doesn't work for CSS and JS files

    
    

    
  
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.

Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

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

    
  
Target Milestone: M15 → M16

    
    

    
  
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.
Target Milestone: M16 → M17

    
  
Keywords: beta2
Whiteboard: workaround checked in → workaround checked in, ? days

    
  
Keywords: nsbeta2

    
    

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

Assignee: gordon → davidm
Status: REOPENED → NEW
Keywords: beta2
Whiteboard: workaround checked in, ? days → workaround checked in, 5 days

    
  
No longer blocks: 11349

    
    

    
  
Putting on [nsbeta2-] radar. Adding nsbeta3 keyword for performance work in PR3.
Keywords: nsbeta3
Whiteboard: workaround checked in, 5 days → [nsbeta2-]workaround checked in, 5 days

    
    

    
  
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
Assignee: davidm → gagan

    
    

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

    
    

    
  
->neeti 
Assignee: gagan → neeti

    
  
Status: NEW → ASSIGNED

    
    

    
  
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+
Whiteboard: [nsbeta2-]workaround checked in, 5 days → [nsbeta2-][nsbeta3+]workaround checked in, 5 days

    
    

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

    
    

    
  
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.
Whiteboard: [nsbeta2-][nsbeta3+]workaround checked in, 5 days → [nsbeta2-][nsbeta3+]

    
    

    
  
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/
Keywords: testcase
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3+] hit during nsbeta2 standards compliance testing

    
    

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

    
    

    
  
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.
Keywords: rtm
Whiteboard: [nsbeta2-][nsbeta3+] hit during nsbeta2 standards compliance testing → [nsbeta2-][nsbeta3-] hit during nsbeta2 standards compliance testing

    
    

    
  
not going to happen for rtm
Whiteboard: [nsbeta2-][nsbeta3-] hit during nsbeta2 standards compliance testing → [nsbeta2-][nsbeta3-] [rtm-] hit during nsbeta2 standards compliance testing

    
    

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



    
    

    
  
*** 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
Keywords: nsbeta1

    
    

    
  
*** 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.
Summary: Memory Cache doesn't work for CSS and JS files → Cache doesn't work for CSS and JS files

    
    

    
  
That makes it crystal clear

    
    

    
  
Sorry for the spam, just adding to CC list.

    
    

    
  
targetting for new cache landing.
Assignee: neeti → gordon
Status: ASSIGNED → NEW
Target Milestone: M17 → mozilla0.9

    
    

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

Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → 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


Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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 :)
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
verified
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: