44 ms·

That re-downloads the file from the server, whereas the Adobe plugin keeps a cache of the file and saves it straight to disk. Most of the time there's no differ

That re-downloads the file from the server, whereas the Adobe plugin keeps a cache of the file and saves it straight to disk. Most of the time there's no difference, but if the PDF came from a single-use URL provided by your bank to view a statement, then there's no way to save the PDF file from the Chrome viewer.

beaumartinez 16y ago
That is certainly a big usability oversight (especially with large PDFs), I remember Chrome used to do that with images as well. However, if those PDFs are requested via HTTP, unless the bank gives appropriate caching headers I think Chrome is technically correct in re-requesting them: they might have changed in the meantime. (I assume it does the same with webpages when you save them.) The fact that the bank gives you a URL you can only HTTP GET once does sound like very bad implementation on their behalf. Perhaps it's a cookie issue, or even a bug in Chrome itself?
- ugh 16y ago
  I don’t consider that to be the correct behavior at all. When I want to save something I want to save it exactly as displayed. Requesting the page again could defeat the whole purpose of saving the page. Here is one example: You opened the front page of some news site a few hours ago and now want to save it. Since news sites change frequently you would save a completely different page compared to what you actually wanted to save if the page were re-requested when saving. This is destructive behavior! No browser should do that. (I just tested what Google Chrome actually does. It does not actually re-request the page when saving.)
- jackshepherd 16y ago
  Chrome also reloads the page when viewing the source-code. Annoying for the same reason. You can see the source-as-is via the inspector but, still...
sesqu 16y ago
I'm using Chrome 8 on linux, and Ctrl-S in the pdf viewer most definitely does not re-download the file. I know this because when I do that, Evince cannot open the saved file (the Chrome version has stuff at the end that the original does not). I always have to go back to the linking site and select "save target as".

beaumartinez 16y ago

That is certainly a big usability oversight (especially with large PDFs), I remember Chrome used to do that with images as well. However, if those PDFs are requested via HTTP, unless the bank gives appropriate caching headers I think Chrome is technically correct in re-requesting them: they might have changed in the meantime. (I assume it does the same with webpages when you save them.) The fact that the bank gives you a URL you can only HTTP GET once does sound like very bad implementation on their behalf. Perhaps it's a cookie issue, or even a bug in Chrome itself?

ugh 16y ago
I don’t consider that to be the correct behavior at all. When I want to save something I want to save it exactly as displayed. Requesting the page again could defeat the whole purpose of saving the page. Here is one example: You opened the front page of some news site a few hours ago and now want to save it. Since news sites change frequently you would save a completely different page compared to what you actually wanted to save if the page were re-requested when saving. This is destructive behavior! No browser should do that. (I just tested what Google Chrome actually does. It does not actually re-request the page when saving.)
jackshepherd 16y ago
Chrome also reloads the page when viewing the source-code. Annoying for the same reason. You can see the source-as-is via the inspector but, still...

sesqu 16y ago

I'm using Chrome 8 on linux, and Ctrl-S in the pdf viewer most definitely does not re-download the file. I know this because when I do that, Evince cannot open the saved file (the Chrome version has stuff at the end that the original does not). I always have to go back to the linking site and select "save target as".