Closed
Bug 530288
Opened 15 years ago
Closed 10 years ago
Cached data is redownloaded when using "save link as"
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: hramrach, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 When downloading an image through a link using "Save link as" the download manager goes through long "Starting ..." phase which can be only accounted to establishing connection and then starts downloading the file bit by bit. When I just middle-click the lina a tab immediately appears with fully loaded image, its miniature as the tab icon and everything. This can only mean that the image is cached bu the cached copy is not used by "Save link as ..." Reproducible: Always Steps to Reproduce: 1. go to a page which provides image download links and provides the same images as thumbnails (possibly shrinked by css) or cache the images by visiting them 2. middle-click the image link 3. right-click an image link and save it Actual Results: the new tab with the image appears immediately but the download manager downloads a new copy of the image from the server Expected Results: the download manager should pull a copy form the cache
This is a huge problem for me regarding saving anything to do with images. Save image as, save page as, everything redownloads all the images on the page. I don't expect it redownloads the HTML, because I use it on javascript generated pages. I'm going to look through more bugs to see if I can find something for this, if not I'll submit a bug. It's rather annoying, and it's been a "feature" for at least 7 months as in http://www.howtogeek.com/forum/topic/why-does-firefox-downloads-the-cached-image-again-while-saving
This is also duplicated by https://bugzilla.mozilla.org/show_bug.cgi?id=548576
Comment 3•14 years ago
|
||
do you see this in safe mode or a new profile?
Whiteboard: [closeme 2011-01-20]
Reporter | ||
Comment 4•14 years ago
|
||
I see this with fresh profile on Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20110103 Firefox-4.0/4.0b9pre http://veimages.gsfc.nasa.gov//7100/world.topo.bathy.200401.3x5400x2700.jpg takes a few seconds to load initially and subsequently displays immediately but download always takes a few seconds.
Reporter | ||
Comment 5•14 years ago
|
||
Happens in safe mode as well.
Reporter | ||
Comment 6•14 years ago
|
||
also duplicated in bug 410737
Updated•13 years ago
|
Whiteboard: [closeme 2011-01-20]
Version: unspecified → 4.0 Branch
Comment 8•13 years ago
|
||
This bug was reported using a pre-release version of Firefox 4. Now that Firefox 4.0.1 final has been released, can you please update and retest your bug? A fresh profile would be a good starting place to test, http://support.mozilla.com/kb/Managing+profiles. If you continue to see the issue, can you please update this bug with your results? Filter: firefox4prebugsunco
Reporter | ||
Comment 9•13 years ago
|
||
Still a problem with Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110531 Firefox/7.0a1 tested on http://science.ksc.nasa.gov/shuttle/missions/sts-113/images/images.html
Updated•13 years ago
|
Version: 4.0 Branch → Trunk
Updated•11 years ago
|
Component: General → Networking: Cache
Product: Firefox → Core
Comment 10•10 years ago
|
||
I have a question about his bug: In the cache control portion of HTTP 1.1 : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html would the right click Save as .... option require the cache control feild to be http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Or is it up to the developer to insert the always or never validate attribute: [https://developer.mozilla.org/en-US/docs/XUL/image] Is it that there is no longer a single image cache? [https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/imgICache]?
Comment 11•10 years ago
|
||
This bug also affects other filetypes as well. The other day i opened a large PDF (conference proceedings) which took a long time. I then hit [CTRL]+[S] and firefox the downloaded the very same file a second time. What a waste of ressources!
Comment 13•10 years ago
|
||
i think i figured out what causes this. i noticed that when disk cache fills up (it never seems to empty out, so eventually it maxes out and nothing new gets cached. my firefox tends to crash a lot when its ram use goes over 2-3 gb, which might be related), the images will stop getting cached, and so, can't be copied from the cache. if you delete all your cache, image saving begins working again.
Comment 14•10 years ago
|
||
@yarrmateys Thank you! This solved my problem. I couldn't "save image as..." without it re-downloading (which many times will fail due to hotlink blocking), but clearing the cache fixed it and images are saving normally from cache now. I also increased my cache size since it seems no one is very interested in solving the way FF manages its cache, and in turn this problem. Cheers
Comment 15•10 years ago
|
||
Works for me - using the example in comment 9 and Firefox 36 nightly.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Comment 16•9 years ago
|
||
@Kevin: Did you first allow your cache to become filled, as detailed by yarrmateys (eg, by spending a lot of time on image-heavy sites)? I'm still seeing this in the released "stable" 35.0.1 build. Even a browser restart isn't sufficient to sort it, I've gotta empty it out via Clear History.
You need to log in
before you can comment on or make changes to this bug.
Description
•