Closed
Bug 73905
Opened 24 years ago
Closed 24 years ago
CSS/JS documents are not cached.
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: bugs, Assigned: darin.moz)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Steps to reproduce:
- have prefs for 'check page for updates' set to 'Never'
- go to a page with static content (e.g. www.mozilla.org)
- go to another page with static content (e.g. go to the 0.8.1 release notes
page from www.mozilla.org's front page)
- click 'Back'
Actual results:
- some form of network connection made, prolonged throbber activity (perhaps
it's checking for updates anyway?) then the previous page is loaded immediately
from cache.
Expected results:
- previous static page loads instantly from cache, without any network activity.
This additional network traffic is unnecessary given this pref setting, and eats
up a lot of time going back and forward. For comparison, try this in Internet
Explorer or Netscape 4 and you'll see it behaving correctly.
Reporter | ||
Comment 1•24 years ago
|
||
nominate for beta as this makes back & forward performance slower than they need
to be.
Keywords: nsbeta1
Reporter | ||
Comment 2•24 years ago
|
||
bbaetz tells me that CSS/JS files are loaded with pragma: nocache. This seems
wrong... (and seems like it would affect a lot of pages)
Assignee | ||
Comment 3•24 years ago
|
||
ben: can you confirm that the only network traffic you are seeing is CSS?
i will look for the bug in which CSS caching was disabled...
Assignee | ||
Comment 4•24 years ago
|
||
i can't find the bug... but there is a spot someplace in layout where the
HTTP request headers are tweaked for CSS downloads to make them non-cacheable.
Assignee | ||
Comment 5•24 years ago
|
||
jud: if i recall, you wrote the patch to disable CSS caching in the old world...
what was the reason for doing this back then? do you remember the corresponding
bug? thx!
Target Milestone: --- → mozilla0.9
Comment 6•24 years ago
|
||
Let this bug be a lesson to me in not checking in someone else's code. I have no
idea. There was some problem where css on some page wasn't getting used or
something. sorry :-/. I suppose we could turn caching on for these again and see
what happens.
Assignee | ||
Comment 7•24 years ago
|
||
changing summary
Summary: Pref 'Check page for updates [ ] Never' does not seem to work → CSS documents are not cached.
Assignee | ||
Comment 8•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 9•24 years ago
|
||
I'm confused about CSS, JS, and XBL files. Here's the behavior I would expect
for a setting of "Once per seesion."
(1) I go to an HTML page and fetch it and all the CSS, JS, and XBL files into my
cache.
(2) At some later point, I go there again. The HTML page is pulled out of the
cache without checking. I would expect the CSS, JS, and XBL files also to be
pulled out of the cache without checking.
(3) I hit reload. Now I should check the server not only for the HTML files but
also for the CSS, JS, and XBL files.
I'm wondering if (3) will still be broken with this patch. With a load of
NORMAL, in the reload situation, will you still just grab the CSS, JS, and XBL
out of the cache without actually pinging the server?
In the case of CSS, JS, and XBL, it seems that they should inherit load
attributes from the load attributes for the parent HTML page. Or am I missing
something here?
Assignee | ||
Comment 10•24 years ago
|
||
they should inherit load attributes from the parent page automagically when
they are added to the load group for the page. the settings in nsCSSLoader.cpp
are simply initial load attributes for the page.
however, that being said... this appears to be broken!! neither the GIF
nor the CSS for www.mozilla.org get downloaded upon shift-reload. but, i
think this is a separate bug that probably belongs to the docshell.
rpotts: am i correct in blaming docshell for not handling shift-reload correctly?
Comment 11•24 years ago
|
||
Ah, ok. XBL is set up correctly then.
Comment 12•24 years ago
|
||
I thought I added this to the bug (maybe I only mentioned it to Ben on IRC): see
bug #46599, which was an RTM workaround for bug 29370, which is scheduled for
0.9. That bug mentions problems which are "timing related". No idea if they
still exist in the new cache, but this bug is probably a dupe of 29370.
images are probably a separate issue: see bug 73450. pavlov muttered the magic
"loadattributes" word in that.
Comment 13•24 years ago
|
||
r=pierre
Reporter | ||
Comment 14•24 years ago
|
||
Hm, I swear I put a comment in here before, but maybe bugzilla lost it.
This is not just for CSS files, but for JS files loaded into HTML documents via
the HTMLContentSink too. Look in ProcessSCRIPTTag in nsHTMLContentSink and
you'll see js files being loaded with FORCE_RELOAD. nsXMLContentSink does not
pass a final parameter, so the default of LOAD_NORMAL is used. So it seems that
this patch needs to be applied in two places.
Summary: CSS documents are not cached. → CSS/JS documents are not cached.
Comment 15•24 years ago
|
||
sr=waterson. What's the bug # about inheriting the load attributes from parent?
Might want to refer to that from here...
Assignee | ||
Comment 16•24 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 17•24 years ago
|
||
Probably a bit late, but perhaps the reason for this was bug #29370 ? See also
bug #17309 for related discussion.
- Biswa.
You need to log in
before you can comment on or make changes to this bug.
Description
•