User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b11) Gecko/20110211 Firefox/4.0b11 Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b11) Gecko/20110211 Firefox/4.0b11 Please see the screencast attached. Reproducible: Always Steps to Reproduce: 1. Load a page, wait so it is loaded completely. 2. Pick an image and choose "Save image as..." 3. Save it to a location. Actual Results: The image is downloaded over again though it is already in cache. Expected Results: It is much faster, convenient and logical when data is copied from cache. This is how it is done in browsers. Tested on Fedora 14 Firefox 4 Beta 11 build by Tom 'spot' Callaway. https://fedoraproject.org/wiki/User:Spot http://repos.fedorapeople.org/repos/spot/firefox4/ http://repos.fedorapeople.org/repos/spot/firefox4/fedora-firefox4.repo firefox4-debuginfo-4.0-0.13.b11.fc14.x86_64 firefox4-4.0-0.13.b11.fc14.x86_64 xulrunner-devel-188.8.131.52-5.fc14.x86_64 xulrunner-184.108.40.206-5.fc14.x86_64 xulrunner2-2.0-0.12.b11.fc14.x86_64
Are you sure that the image is cached ? What are the http headers for this image ? You didn't provide an example URL. It's reported that this should work (bug 120809) BTW: the server sends the video from comment#1 as text/plain and my browser renders it as text/plain as it should.
I am reporting the feature broken. Please watch the screencast.
I know what you are reporting and i watched the video. Your Steps to reproduce are incomplete. >1) 1. Load a page, wait so it is loaded completely. http://apage.com/ is empty :-) Always provide examples in a bug report. I have to manual copy the URL from your video which should is unnecessary. >The image is downloaded over again though it is already in cache. How do you know that it's in the cache and not expired ? That depends on the http headers for the image and that is the reason why "a page" isn't enough. I'm sure that your used example page prevents the caching. The image URL is immediately a 404 after watching it ! The server sends this headers : Status: HTTP/1.1 200 OK Date: Sun, 13 Feb 2011 16:08:52 GMT Server: Apache Last-Modified: Sun, 13 Feb 2011 01:04:04 GMT ETag: "104620-2c603a-49c1f81e48900" Accept-Ranges: bytes Content-Length: 2908218 Connection: close Content-Type: image/jpeg There are no additional cache headers and last modified is very recent which results in a very short cache time (AFAIK time/10=cache time). The etag for revalidation is useless because the image is already gone (404) on the server after you watched it. My Gecko is using the cache for image downloading if you use an older image from that page which result's in a longer cache time and if you are fast enough. This report with the given URL is invalid if the image is already expired based on the very recent if-modified and the etag fails because the server reports a 404. This bug is however worksforme with Seamonkey trunk and FF4.0b11 if I use an image that isn't already expired.
I'm sorry, but I don't know what is an HTTP header and how to see it. If an image is in the browser window it is on the PC, right? All that I know and that matters to me is that: 1. it doubles waiting time; 2. it doubles the cost. I can not remember another browser that does the same. As a user, I can clearly see that, first, the feature does not perform well. Second and more important is that using Firefox drains my money.
>If an image is in the browser window it is on the PC, right? No ! The browser doesn't have the original file anymore, only the decoded data. >I'm sorry, but I don't know what is an HTTP header and how to see it. -> http://en.wikipedia.org/wiki/HTTP_header The server sends headers that either allow caching or not and depending on the headers the client knows how long content should be cached and if the contents must be revalidated. The caching rules are specified in the http RFC. You can see the cache contents with about:cache You used the newest image on that page with a very recent if-modified header. Please try it again with an older image.
> >If an image is in the browser window it is on the PC, right? > > No ! > The browser doesn't have the original file anymore, only the decoded data. As much as I can see on the website, the button says "Download", so the actual file is being _downloaded_ to my PC (and I can see the process in the browser window). Also, Chrome and Opera do not require a second-time download, so it must be possible to save (or restore?) the file from its representation. > -> http://en.wikipedia.org/wiki/HTTP_header I've looked through, thanks. I've seen no reason why I have to be experiencing this inconvenience explained, though. > Please try it again with an older image. Downloading (and "Saving images as...") from the page 200 (year 2005) gives the same result and does not solve the problem. What is this all for, anyway?
>As much as I can see on the website, the button says "Download", so the actual >file is being _downloaded_ to my PC The file isn't downloaded to a file because the website doesn't tell the client that the content of the URL should be saved. The Client (Gecko) downloads and renders this file instead because it's an internal supported content-type. And as I already explained, the caching of the original file depends on the header sends by the server. The website could force a download, it just have to send a content-disposition:attachment header. >Downloading (and "Saving images as...") from the page 200 (year 2005) gives the >same result and does not solve the problem. That works for me with Seamonkey trunk and FF4.0b11 (as I already posted). The cache is used and there is only a small delay for copying the file on the Filesystem. >What is this all for, anyway? I don't understand what you mean. I triedto explain that the caching depends on a few things and that the original image that is displayed can't be used anymore because it's not the original file. That you didn't know about this things is clear if I watch the summary. It works for me if the image is in the cache and must not be validated again and I try to find the reason if that doesn't work for you Please create an additional test profile and test again with this profile: http://support.mozilla.com/kb/Managing%20profiles
Incomplete due to the follow-up asked at the end of comment 8.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.