Closed Bug 92824 Opened 23 years ago Closed 23 years ago

For 'Back' on expired POST doc, history goes back despite Cancel.

Categories

(Core :: DOM: Navigation, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: jrgmorrison, Assigned: radha)

References

()

Details

Attachments

(3 files)

Overview Description: If you attempt to go Back to a page that was a response to a POST form submission, and that response has expired from the cache, you are presented with a dialog: "The page you are trying to view contains POSTDATA that has expired from cache. If you resend the data, any action the form carried out (such as search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel" If you hit Cancel, then the current page remains on screen and the POST is _not_ submitted. Okay, that's all fine. However, the session history is moved back, so that target of the forward button is the current document. Steps to Reproduce: 1) Load http://cowtools.mcom.com/cgi-bin/bugs/92598/no-store-POST-GET.pl This cgi will send out the headers "Cache-control: no-cache, no-store", which will prevent the response document from being held in the cache. 2) i) Using the POST form on that page, enter the value "111". Hit submit. ii) Using the POST form on that page, enter the value "222". Hit submit. iii) Using the POST form on that page, enter the value "333". Hit submit. 3) Now hit the Back button. You will get a dialog. Select "Cancel". Actual Results: a) the current document remains visible, and the POST is not sent. b) however, the History has been moved back one document. Expected Results: The History should not go back. When you cancel the POST, you have not moved back to the previous document. ---- If you hit "Back" again, and "Cancel", history is now moved to the "-2" position. If you continue to do this, eventually you will return to the original load of the form, which was done on a GET (and this form will be executed automatically as a GET, but that's OK). Reproducibility: 100% Build Date & Platform Bug Found: 2001-07-27-12-trunk win2k
Attached file test case program from cowtools URL (deleted) —
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.5
*** Bug 97972 has been marked as a duplicate of this bug. ***
Attached patch Initial patch (deleted) — Splinter Review
The attached patch includes the following changes: 1) In nsISHEntry.idl, change the name of the attribute saveHistoryStateFlag to saveLayoutStateFlag, (for better understanding) 2) Changes related to #1 in nsSHEntry.h and nsSHEntry.cpp 3) Add a new method UpdateIndex() to nsISHistoryInternal.idl 4) Changes related to #3 in nsSHistory.cpp 5) When a new history load is initiated, the index to which the traversal is made is stored in a new member variable "requestedIndex" in nsSHistory.h. The actual index "mIndex" is updated to the requestedIndex, by docshell, only after the OnStartLoad() is called for the url. nsDocShell::OnNewURI() calls nsSHistory->UpdateIndex() to do that. This is the crux of the fix to the bug. This kind of move was not required till now, because the cache wasn't really up-to-date with what SH wanted and SH had more control on how history loads. Now that no-cache no-store related features are in place in cache, we need to update session History to deal with that. I think this is a good move because the back and forward buttons are also updated right around this time from nsDocShell::OnNewURI(). 6) In nsWebShell.cpp, when a post data result page is loaded from history and it is not found in cache, we throw up a dialog to the user asking permission to repost the data. When the user clicks OK in the dialog enabling us to repost the date to the server, we update the index in history index. This change is similar to the new code added in nsDocShell::OnNewURI(). 7) Finally in navigator.js, we don't need to explicitly call UpdateBackForwardButtons(), since the onLocationChange() notification will do that job for all cases including subframes.8) This patch also fixes a recent regression caused by all the newly added members to nsSHEntry.h. Changes related to that are in nsDocShell::CloneAndReplace()
hey radha, this is a BIG patch :-) It looks really good to me... I just had a couple of small comments... 1. Can 'requestedIndex' be renamed to 'mRequestedIndex' to indicate that it is a member variable. 2. in nsSHistory.cpp in the line 584 mod block, there is: + if (!nextEntry || !prevEntry || !nHEntry) { return NS_ERROR_FAILURE; } should this be: + if (!nextEntry || !prevEntry || !nHEntry) { + requestedIndex = -1; return NS_ERROR_FAILURE; } so that if the operation fails, rather than having requestedIndex set to the previous value, it gets reset to -1 ? other than that, r/sr=rpotts@netscape.com
Looks okay to me too. r=adamlock Radha, can you change the formatting for nsDocShell.cpp to match the "house style" before check-in? That file is slowly becoming a morass of different formatting conventions even though it was run through indent not too long ago.
This was fixed on friday.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: