Last Comment Bug 39957 - 'Save as...' not fetching from cache
: 'Save as...' not fetching from cache
: dataloss
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: x86 All
P1 normal (vote)
: ---
Assigned To: Bill Law
: Tom Everingham
Depends on:
  Show dependency treegraph
Reported: 2000-05-20 06:39 PDT by Paul LeBeau
Modified: 2004-11-23 18:54 PST (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Fix to use VALIDATE_NEVER when saving page/image/bg-image/unk-content. (3.97 KB, patch)
2000-08-25 16:05 PDT, Bill Law
no flags Details | Diff | Splinter Review

Description User image Paul LeBeau 2000-05-20 06:39:50 PDT
'Save as..' appears to be refetching the page rather than
retrieving it from the cache.

I'm not sure this is happening every time (I have a fast link
so it's not always obvious :), as I have had at least one
saved file which was truncated (after first fetch was
interrupted).  This tends to suggest that either the cache
*was* being used - or the truncated file size (rather
than the correct size) was being remembered.
Comment 1 User image Paul LeBeau 2000-05-20 08:00:43 PDT
Forgot to mention - using M15.  Don't know about other versions.

Comment 2 User image Matthew Paul Thomas 2000-05-20 20:43:36 PDT
Save, Print, Send Page, etc should always use the cached version, regardless of 
the document's caching settings. Otherwise the version being saved/printed/
forwarded could be completely different from the version on the screen, which 
would be bad.
Comment 3 User image WD 2000-05-21 20:22:53 PDT
Yes this is a problem.     It's one of the things that I've hated with
Netscape...    If I want to print a page that I'm looking at right now, why on
earth would it request a new copy from the network?    I want to print (or save,
forward, whatever) what I've got on the computer at that moment.   (in the cache)

There have been a couple of bugs similar to this one filed which ended up
getting marked as dupes of bug 21137.    Personally, I don't see the connection.
  I'm confirming this as new.
Comment 4 User image davidm 2000-05-23 18:03:19 PDT
This isn't really a cache bug. The save as peopple and print people should be 
setting the channel flag not to do any validation which will cause the cache to 
be used if the data is available ( it could be flushed if you have multiple 
windows open). I can't actually see where they are loadin the URLs but thats the 
Comment 5 User image neeti 2000-06-09 10:53:57 PDT
I am not sure if you are the right person for this bug. Please reassign as 
necessary. I think we should be using SelectFileAndTransferLocation(.., instead 
of SelectFileAndTransferLocationSpec(..) in function savePage in navigator.js.

Comment 6 User image Stephen Moehle 2000-07-21 10:15:05 PDT
It would be nice to get this fixed sooner rather than later.  I cannot save any
page that was created as the result of POST data.  It seems saving the page
submits the URL but without any of the POST data so it always saves some default

For instance, go to
and enter a number in the "Show me" field that produces more than 50 results
which would be more than one page.  Go to the second page and do "File/Save Page
As".  The first page will be saved not the second page displayed in Mozilla.
Comment 7 User image Dan Rosen 2000-08-23 17:52:11 PDT

*** This bug has been marked as a duplicate of 6119 ***
Comment 8 User image Jesse Ruderman 2000-08-23 18:27:03 PDT
i think this should be kept as a separate bug from bug 6119.  adding dataloss 

should this be marked as dependent on bug 40867, like bug 6119 is?  or would it 
be sufficient to use a cached version?  (i guess this depends mostly on whether 
we always cache everything.)
Comment 9 User image Matthew Paul Thomas 2000-08-23 23:12:46 PDT
No, you shouldn't get a new version even if you have zero cache. Or you might 
want to save a form submission where the server told Mozilla not to cache it, for 
Comment 10 User image leger 2000-08-24 03:45:08 PDT
ccing gagan, updating QA contact.  Putting on [dogfood+] radar and nominating 
for nsbeta3. I use this constantly. Must work for my dogfood. :-)
Comment 11 User image johng 2000-08-24 12:35:24 PDT
nav triage team:
nsbeta3+, P1
Comment 12 User image Bill Law 2000-08-25 14:08:42 PDT
I've added code that does SetLoadAtributes( nsIChannel::VALIDATE_NEVER ); and it
sort of works.  I'm still seeing scenarios where either the wrong page is coming
from the cache or it's going back to the server.

For example, my fix does not fix the problem with
Comment 13 User image Bill Law 2000-08-25 16:05:51 PDT
Created attachment 13521 [details] [diff] [review]
Fix to use VALIDATE_NEVER when saving page/image/bg-image/unk-content.
Comment 14 User image Bill Law 2000-08-25 16:16:19 PDT
I'm going to assign this to Networking again.  I've fixed my code to use 
VALIDATE_NEVER whenever we reload data to save it.  As far as I know, that's the 
best I can do for now.

A problem still exists, as demonstrated by the oreillynet meerkat page.  I don't 
understand exactly what's happening.

I'm going to talk to Radha on Monday morning and try to find out what's going 
on.  It's a situation somewhat akin to session history forward/back.
Comment 15 User image Dan Rosen 2000-08-30 11:49:20 PDT
adding cc
Comment 16 User image leger 2000-08-30 18:09:03 PDT
PDT agrees P1
Comment 17 User image Bill Law 2000-08-31 14:06:06 PDT
We have a problem resubmitting loads for any page loaded with form post data.

This applies to view-source and saving pages.

I've been talking to Radha about how to get the post data stream from session 
history by way of the docshell, but it has proven to be difficult.
Comment 18 User image leger 2000-09-06 15:05:35 PDT
Putting [pdtp1] in whiteboard
Comment 19 User image Bill Law 2000-09-12 15:19:35 PDT
I've checked in the patch I posted previously, plus code to resupply the form 
post data, if required.

There is still bug 20843 that can cause problems.  This produces a cache miss or 
mishit for pages involving form post data.  This seems to happen with that 
oreillynet/meerkat page (the cache erroneously returns the first page with 
matching url even though that one has different form post data).
Comment 20 User image sairuh (rarely reading bugmail) 2000-10-04 15:35:53 PDT
should prolly go to tever for verification...
Comment 21 User image Tom Everingham 2000-10-24 20:07:39 PDT
WinNT 1024
Linux rh6 1024
Mac os9 1024
Comment 22 User image Deven Corzine 2000-12-28 15:03:12 PST
As with bug 6119, this bug isn't really fixed.  Or, I should say, it's "fixed"
in that it's loading from the cache if possible, but not fixed in the sense of
always behaving as the user expects "Save As" to behave.  This bug should depend
on bug 40867, since it's a more fundamental problem.

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