Closed
Bug 39957
Opened 24 years ago
Closed 24 years ago
'Save as...' not fetching from cache
Categories
(SeaMonkey :: UI Design, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: paul.lebeau, Assigned: law)
Details
(Keywords: dataloss, Whiteboard: [dogfood+][nsbeta3+][pdtp1])
Attachments
(1 file)
'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.
Reporter | ||
Comment 1•24 years ago
|
||
Forgot to mention - using M15. Don't know about other versions.
Comment 2•24 years ago
|
||
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
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 theory;)
Bill, 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. Neeti
Assignee: gordon → law
Comment 6•24 years ago
|
||
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 page. For instance, go to http://www.oreillynet.com/meerkat/ 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.
*** This bug has been marked as a duplicate of 6119 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 8•24 years ago
|
||
i think this should be kept as a separate bug from bug 6119. adding dataloss keyword. 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•24 years ago
|
||
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 example.
Depends on: 40867
Comment 10•24 years ago
|
||
ccing gagan, updating QA contact. Putting on [dogfood+] radar and nominating for nsbeta3. I use this constantly. Must work for my dogfood. :-)
Comment 11•24 years ago
|
||
nav triage team: nsbeta3+, P1
Priority: P3 → P1
Whiteboard: [dogfood+] → [dogfood+][nsbeta3+]
Assignee | ||
Comment 12•24 years ago
|
||
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 oreillynet.com/meerkat.
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Comment 14•24 years ago
|
||
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•24 years ago
|
||
adding cc
Comment 16•24 years ago
|
||
PDT agrees P1
Assignee | ||
Comment 17•24 years ago
|
||
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.
Status: REOPENED → ASSIGNED
Comment 18•24 years ago
|
||
Putting [pdtp1] in whiteboard
Whiteboard: [dogfood+][nsbeta3+] → [dogfood+][nsbeta3+][pdtp1]
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
No longer depends on: 40867
Resolution: --- → FIXED
Assignee | ||
Comment 19•24 years ago
|
||
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 21•24 years ago
|
||
verified: WinNT 1024 Linux rh6 1024 Mac os9 1024
Status: RESOLVED → VERIFIED
Comment 22•24 years ago
|
||
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.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•