Closed Bug 84106 Opened 23 years ago Closed 16 years ago

[FIX]Not correctly retrieving post data when saving a page or frame generated from a form POST


(Firefox :: File Handling, defect, P2)






(Reporter: joe, Assigned: bzbarsky)


(Blocks 1 open bug, )


(Keywords: dataloss, relnote)


(1 file, 2 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-1mdk i586; en-US; rv:0.9+)
BuildID:    2001060421

Mozilla does not save the respond to a posted form correctly.
Instead of saving the posted reply, it saves the form.

Reproducible: Always
Steps to Reproduce:
1.go to the referenced form
2.type in a URL in the big text box (say
3.push dumplinks
4.The form correct displays the page source
5. Now try saving the output
6. You get the form itself and not the response

Actual Results:  You get the form output

Expected Results:  You should get the dumped page.  You do get that in netscape
See bug 78740.  Please do _not_ mark this duplicate, but rather leave it open to 
track this issue.

dataloss, since saving a page can save nothing useful for dynamic pages and the 
user is screwed if (s)he forgets to check in another browser window what 
actually got saved.
Assignee: asa → pchen
Severity: normal → major
Component: Browser-General → XP Apps
Depends on: 40867
Ever confirmed: true
QA Contact: doronr → sairuh
Hardware: PC → All
Summary: Reply from posted form not saved correctly → "Save As" reloads from network
->bill? or, is this a networking issue?
Assignee: pchen → law
nav triage team:

This should retrieve the document from the cache. Reassigning to gagan
Assignee: law → gagan
Component: XP Apps → Networking: Cache
the change required to make this happen (from cache) is still with whoever calls
into networking. You just have to make sure you set the right flag--
LOAD_FROM_CACHE. (for reference-- see the history implements this) Back to you
Assignee: gagan → pchen
nav triage team:

Marking nsbeta1+, p2, and mozilla0.9.3
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
-> XP Apps.

If you need help w/ testing, let us know. There are probably enough examples in
public URL's for this one.
Component: Networking: Cache → XP Apps
Keywords: relnote
Keywords: nsenterprise
nav triage team:

Marking nsBranch
Keywords: nsBranch
*** Bug 88031 has been marked as a duplicate of this bug. ***
So here:

we actually set the LOAD_FROM_CACHE flag, and from simple testing, we appear to
corrrectly load from the cache.

I believe the bug here is that we aren't getting the post data from session
history (in fact, nsStreamTransfer::SelectFileAndTransferLocationSpec() is
getting passed in null for the postData parameter), in effect, when saving, we
get the source for the initial form page (though, I think that it was actually
retrieved from the cache).

Resummarizing to "Not correctly retrieving post data when saving a page
generated from a form POST".

I think this bug is now less severe than originally stated, but I will leave it
up to the triage team to determine the fate of this bug.
Summary: "Save As" reloads from network → Not correctly retrieving post data when saving a page generated from a form POST
nav triage team:

(Yes, it's really nav triage team, not just me ;-) )

Bug not as severe as orignally stated, moving out to mozilla1.0 and removing
nsBranch keyword
Keywords: nsBranch
Target Milestone: mozilla0.9.3 → mozilla1.0
See patch posted to bug 40867
( for a fix to
this problem.
The patch there fixes "save as" but not "save frame as"
Summary: Not correctly retrieving post data when saving a page generated from a form POST → Not correctly retrieving post data when saving a page or frame generated from a form POST
*** Bug 90836 has been marked as a duplicate of this bug. ***
Depends on: 90722
marking nsenterprise-.
spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)
Component: XP Apps → File Handling
moving to mozilla0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9
->default owner
Assignee: pchen → law
Target Milestone: mozilla0.9.9 → ---
Boris, any idea where this bug stands with respect to the new save logic?  I
know we're preserving the post data stream but I don't know if that's sufficient
in light of the fix Vidur  mentions that also wants to use some sort of cache key.
That's not sufficient...  What we really want to be able to do is to pass a
cache key to webbrowserpersist.  The back end code will then want to QI the HTTP
channel to a caching channel and set the cache key on that.  This will do two

1)  Allow us to retrieve the correct document from the cache
2)  Allow us to put up a dialog for the user in cases when the document has
    expired from the cache (instead of silently reposting).

See the code in nsDocShell::DoURILoad that handles this case for history loads.
 Saving should be just like history in this regard, imo.
Thanks, turning this over to Adam.
Assignee: law → adamlock
Target Milestone: --- → Future
*** Bug 128719 has been marked as a duplicate of this bug. ***
*** Bug 159382 has been marked as a duplicate of this bug. ***
I have a problem saving frames from a dynamic page (on my intranet, I can't
offer you a url, sorry), which looks like it might be related to this bug, but
I'm not sure.  I *don't* have the problem where the original form is saved
instead of the dynamic page.

The page has two frames.  I can save the whole page, that works fine.  But if I
try "Save Frame As" to just get the one frame, mozilla (1.0) refuses, saying
"The link could not be saved. The web page might have been removed or had its
name changed."

So mozilla appears to be trying to access the frame's url anew, instead of using
the HTML it already downloaded.

The odd thing is that I can view the source of the frame, that also works fine.
 But if I try to save the page from the Frame Source view, then it still fails,
with the same error message.

Should this be filed as a separate bug?

Drew Parsons
There appears to be a bug with Netscape 6/7 Post transactions.  I noticed some
questions about this on a list-serve to which I subscribe, but never paid much
attention to it.

However, a couple of weeks ago I did download Netscape 7 and switched to it from
Net 4.7 as my standard browser.  Yesterday, I started some work on new features
for the NCHA web site, and noticed the problem.

It looks to me like the application server is waiting for the POST to be
completed.  Interestingly, I can simultaneously run the same application query
from IE without problems.  An example that shows this:

This is a Tango Application server, but there are apparently similar issues with
Tomcat and perhaps others.

This is a production server, and I have a limited number of connections
available, so while it's okay to hit the server to see the problem, if anyone
wants to use it for debugging, I would rather set you up with a separate URL on
a development machine.
QA Contact: sairuh → petersen
By the definitions on <> and
<>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
Blocks: 115174, 120809
The OS should be All.
OS: Linux → All
Mozilla doesn't even warn the user that data are reposted. Even if this bug
(reload avoided) cannot be fixed for the moment, I think that until this bug is
completely fixed, Mozilla should display a warning box, where the user can
cancel the repost. This would be very useful, as duplicates may really be
harmful (on sites that can't detect them).
Note bug 288462.
Blocks: 288462
Blocks: 472895
OK, the core part of this has been done ever since bug 170722 landed.  All that needs to happen is for our front-end to actually pass the right data into nsIWebBrowserPersist.
No longer blocks: 472895
Gah.  We seem to have no Toolkit component for contentAreaUtils...  I guess I'll toss this in Firefox for now, though it's a toolkit fix.
Assignee: adamlock → nobody
Product: Core → Firefox
QA Contact: chrispetersen → file.handling
Attached patch Fix (obsolete) — Splinter Review
Two things going on here.  The first change isn't really needed to fix this bug, but it's weird for the persistence object to take either an nsIWebPageDesciptor or a necko cache key but NOT the currentDescriptor of an nsIWebPageDescriptor.  This caused my first patch attempt to fail...

The second change is just a change to pass in the nsIWebPageDescriptor for the document we're saving into saveURI.

I'm not quite sure how to write a test for this; I did test locally that it fixes the bug for me in terms of actually hitting the cache for POST data.  I'd welcome any testing suggestions.

On a separate note, I really don't like this idea of reposting if the data is not in cache (as we do now).  We should probably add some flags to nsIWebBrowserPersist to allow LOAD_ONLY_FROM_CACHE and have fallback UI (a prompt? something else?) for when the data is not cached.  Alternately, we need to fix our caching, finally; I'll post to about that.
Assignee: nobody → bzbarsky
Attachment #362349 - Flags: superreview?
Attachment #362349 - Flags: review?(jst)
Attachment #362349 - Flags: review?(
Attached patch Er, with the right comments (obsolete) — Splinter Review
Attachment #362349 - Attachment is obsolete: true
Attachment #362349 - Flags: superreview?
Attachment #362349 - Flags: review?(jst)
Attachment #362349 - Flags: review?(
Attachment #362351 - Flags: superreview?(jst)
Attachment #362351 - Flags: review?(jst)
Attachment #362351 - Flags: review?(
Summary: Not correctly retrieving post data when saving a page or frame generated from a form POST → [FIX]Not correctly retrieving post data when saving a page or frame generated from a form POST
Attachment #362351 - Flags: superreview?(jst)
Attachment #362351 - Flags: superreview+
Attachment #362351 - Flags: review?(jst)
Attachment #362351 - Flags: review+
Comment on attachment 362351 [details] [diff] [review]
Er, with the right comments

+    pageCookie = ifreq.getInterface(Components.interfaces.nsIWebNavigation);

I don't understand where the name "pageCookie" comes from here, but assuming that makes sense here, it's all good :)

Hmm.  That was copy/paste from the view-source code.  Originally probably comes from rpott's mind.  I'm happy to call it cacheKey or something instead.
Attachment #362351 - Flags: review?( → review+
Comment on attachment 362351 [details] [diff] [review]
Er, with the right comments

I agree with jst about "cacheKey". I think it would be worth adding a comment explaining that all nsIWebNavigations are also nsIWebPageDescriptors, or an explicit QI.
(In reply to comment #36)
> (From update of attachment 362351 [details] [diff] [review])
> I agree with jst about "cacheKey".

Er, I agree with you that "cacheKey" would be better than "pageCookie", I mean.
Attachment #362351 - Attachment is obsolete: true

Filed bug 479296 on the remaining issue.  This still needs a test (presumably a browser one), right?
Closed: 16 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Depends on: 480318
Bug 188253 is about porting the fix to SeaMonkey, but for a more comprehensive
solution see bug 484616.
You need to log in before you can comment on or make changes to this bug.