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)
Core
DOM: Navigation
Tracking
()
VERIFIED
FIXED
mozilla0.9.5
People
(Reporter: jrgmorrison, Assigned: radha)
References
()
Details
Attachments
(3 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.5
Assignee | ||
Comment 3•23 years ago
|
||
Assignee | ||
Comment 4•23 years ago
|
||
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()
Assignee | ||
Comment 5•23 years ago
|
||
Comment 6•23 years ago
|
||
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.
Assignee | ||
Comment 8•23 years ago
|
||
This was fixed on friday.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 9•22 years ago
|
||
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.
Description
•