From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-1mdk i586; en-US; rv:0.9+) Gecko/20010604 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 http://www.mozilla.org) 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.

->bill? or, is this a networking issue?

nav triage team: This should retrieve the document from the cache. Reassigning to gagan

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 pchen...

nav triage team: Marking nsbeta1+, p2, and 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.

nav triage team: Marking nsBranch

*** Bug 88031 has been marked as a duplicate of this bug. ***

So here: http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/src/nsStreamTransfer.cpp#177 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.

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

See patch posted to bug 40867 (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=41511) for a fix to this problem.

The patch there fixes "save as" but not "save frame as"

*** Bug 90836 has been marked as a duplicate of this bug. ***

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. :)

moving to mozilla0.9.9

->default owner

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 things: 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.

*** 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: http://www.norcalhandball.org/players/players.taf 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.

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, 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.

The OS should be 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.

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.

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.

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 m.d.t.network about that.

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 :) r+sr=jst

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.

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.

Pushed http://hg.mozilla.org/mozilla-central/rev/31689184423e Filed bug 479296 on the remaining issue. This still needs a test (presumably a browser one), right?

Bug 188253 is about porting the fix to SeaMonkey, but for a more comprehensive solution see bug 484616.