Closed Bug 55055 Opened 23 years ago Closed 23 years ago

Go Back broken for form post results


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






(Reporter: warrensomebody, Assigned: radha)



(Keywords: dataloss, Whiteboard: [rtm-]relnote-user[nsbeta1+])


(4 files)

If you go back in the history to a page that was the result of a form post (e.g.
filing a new bug in bugzilla), you'll get a dialog asking if you want to repost
the form data. This is completely wrong. If you click No, it will end up showing
you an error page instead of the page you saw before when you originally
completed the post.

This is really bad because users can lose valuable data. I lost my bugzilla bug
number (which wasn't a big deal), but you might lose an airline ticket
confirmation number or something.
Nominating for rtm.
Keywords: rtm
This is a tricky one. Please see 43123,46338. Work should be done in docshell
possibly with some interaction with cache. Automatically reposting (while going
back or forward) causes  bad things like purchasing a ticket twice. Not
automatically reposting fails some pages like's search page(bugzilla
bug  # 1718, 17685).

THere is a suggestion to use a 3 button dialog, with "yes" for reposting, "no"
for don't repost, "cancel" -do nothing don't leave the current page.

There is also a suggestion to not automatically repost for back and forward, but
repost for reload. If we do this, we need to have a interim page(just like in
Nav 4.x) instead of a dialog, that sez the page was a result of a post and if
the user wishes to repost the data, he press the reload button. The work
involved spans beyond Session History. cc'ing appropriate enginners and phil who
was recently bitten by this.
Radha, considering how close we are to ship, can we realistically justify
changing this behavior at this point?
Whiteboard: [rtm need info]
I think whatever fix we come with can be justified as long as it is right. I 
know a lot of people hate that dialog. The problem is figuring what the right 
behavior is, considering all the cases that have to be covered. If someone who 
knows how this exactly works in Nav 4.x can do a brain-dump to me, I'm willing 
to spend some time on it.
Note that even with the dialog I can't get the behavior I want. I just want to 
see the result of my last form post. When I clicked the button to not repost the 
data, I got some kind of error page from bugzilla (the one with the big red 
box), saying that I didn't submit the right fields to update the bug.
nav triage team:
since the back button is the most used button, lots of users will eventually run
into this problem, and the work around is undiscoverable, dialog does not make
sense.  So P2.

Let's implement Radha's suggestion Yes, No, Cancel.  Vera will write the text
(because the biggest problem is understanding this).  Radha, Don thinks that we
need to get a patch and super review by Monday to get this in.  Note that if
adding a third button (Cancel) takes too much time, we want to take the text
changes from Vera.

So we want text changes, and possibly adding the Cancel button if we can.

cc'ing verah and jaimejr for l10n.

Priority: P3 → P2
Adding Michele and Monste to cc: list.

I would vote for getting these changes into RTM. People use the back button 
is bug 52635 a dup of this?
Note that we should not ask users at all wheather to repost the form, if we want 
conform to RFC 2616 (HTTP/1.1). Instead we should redisplay the page without
reposting. See my latest comment in bug 43123.

Actually this bug seems to be a dup of bug 43123 and/or bug 46338.
Bug 52635 is a slightly different issue.

I don't think that we need full conformance to RFC 2616 in RTM, but the broken
behaviour of the Cancel button (performing a HTTP GET on the page instead of
doing nothing at all) should be fixed in RTM. More discussion on that issue is
in bug 46338.
I have to agree that the dialog makes no sense. We should always just redisplay 
the previous page contents, and never repost. No dialog is needed. 
It's getting to later to fix this and get it approved for N6 RTM.  Especially
since we don't have consensus yet.  Sorry.  Minus.
Whiteboard: [rtm need info] → [rtm-]
Let's try to get this for 6.01...It's really annoying.
Keywords: ns601
I'm working on a fix as I type this.  Please hold on..
I removed the dialog code. Taking the bugzilla example, I made changes to a
dummy bug(56221)

1) If I don't repost, you will see that error page from bugzilla. (The symptom
warren has described when he first reported the bug).  This is the same behavior
as "Cancel" in the dialog.

2) If I repost you can go back to the bug exactly where you were with form
values retained. However if you press forward now, you will get a mid-air
collision with your own changes to the bug before you clicked Back. I think the
same actions (submit form, go back, go forward) on a site that sells tickets
will result in  double purchase.

When I go back/forward to any page(with or without post data), I'm passing the
VALIDATE_NEVER flag to the channel. This will  try to retrieve the page from
cache. I understand  form post results are not saved in cache. I'm yet to try
the combination of repost, no repost with FORCE_VALIDATE flag. Shall try that
out comment in the bug again.
Few corrections to my previous comment:

1) Load bug 56221. Make some changes to the bug
2) Submit changes.
3) results of form submission occurs(Followed by the next bug in your list, if
you already did a query before you went to 56221)
4) Now I hit back button.

When not reposting:
I go back to the bug page.

When Reposting:
I go back to the bug page.

5) Hit Forward button:

When not reposting:
Bugzilla error

when reposting:
Mid-air collision.
Restoring need info.  Radha, get the fix and the reviews ASAP!
Whiteboard: [rtm-] → [rtm need info]
Depends on: 56346
> I understand  form post results are not saved in cache.

They should be saved in memory cache or by some other mechanism.
I filed bug 56346 on that issue.
using FORCE_VALIDATE seems to have no effect on the behavior. I'm getting the
same results as in the comment I made today at 15:04. 
Okay this may be out in left field, but there is a third option to "Full repost
with postdata" and "Broken POST with no postdata".  My feeling is that we should
offer the user two choices:

Okay) If the user clicks Ok, repost fully
Cancel) If the user clicks Cancel, load about:blank

We should not be sending a POST request to the server without the post data.  No
sites are designed to handle this because no browser does it (except us).  It
seems better to show the user nothing (about:blank) rather than to show them an
error message or the wrong page of a site or <insert random thing here>.

Of course the long term solution is to mimic Nav's behaviour or follow RFC 2616
but we are running out of time.  On the off chance this seems doable, this is
what I see of Nav's behaviour:

For a session history load (not reload):
  Does this entry have post data?
  No: Do the regular thing.
  Yes: Does a cache entry exist for this page?
       Yes: Display it
       No: Change URL to load dummy page "Data Missing: ... recreate the
document by pressing the reload button."

(Notice the behaviour of the first "Yes" changes from "Pop up dialog" to this
cache || dummy load - this makes pressing the Back button much less painful)

For a Reload:
  Are we displaying the dummy page?
  No: Do the regular thing
  Yes: Pop up dialog

For the dialog:
  Okay: Repost the URL complete with all post data
  Cancel: Abort and do not load any URL or post anything
Another way to handle Cancel might be:

Cancel) If the user clicks Cancel, load resource:///res/data-missing.html

Where data-missing.html says something like:

This page is the result of a form post and cannot be displayed at this time.
After going thro this bug and all other related bugs, I think it is not 
appropriate to blindly "post or not post" the data with out warning the user 
about  the consequences. Until 56346(the bug this depends on) is fixed, it is  
not possible to imitate the Nav 4.x behavior. Instead of surprising the user 
with a double post or a error message,I intend to keep the dialog with better 
wording and better action. 

After going  thro' bug 43123(wording for repost dialog not OK), I infer that the 
way the Cancel button behaves in that dialog is in-appropriate. I intend to fix 
that problem and add better description  to the dialog. 

So, the dialog will be a 2 button dialog. Pressing "yes" will repost the form 
data. Currently we do not cache the post data results. So the query will go to 
the server and it will cause double posting (eg., mid-air collision in bugzilla 
pages). Pressing "No" will not do anything. It will just dismiss the dialog and 
the user will be where he was. We will not attempt to load the page with GET. 
I agree that doesn't make sense. That is something the HTTPChannel does when it 
can't find the post data for the cgi. I will attach the patches soon.
I have attached a patch to the bug. Please note that the patch is based on the 
latest trunk builds.
Summary: Go Back broken for form post results → Go Back broken for form post results. Fix in hand. awaiting reviews
Text for the dialog:

If you have already submitted the data in the form on this page, clicking Back
or Forward will cause this data to be submitted again. Are you sure you want to
re-submit the data?

[Yes]  [Cancel]
Summary: Go Back broken for form post results. Fix in hand. awaiting reviews → Go Back broken for form post results.
Whiteboard: [rtm need info] → [rtm need info]Fix in hand. awaiting reviews
I really don't think it ever makes sense to repost the data. Consequently the 
dialog is unnecessary. If the user wanted to repost, they would click the 
button again. The reason for history is that the user wants to go back to the 
page they saw before -- not the latest version of the page on the server. If 
they wanted the latest (or wanted to repost) they'd hit the reload button (or 
click the button on the page again that caused the post in the first place). 
Reload should be the only thing that prompts the user to repost or not.
Radha's patch looks good to me. It fixes the worst misbehavior and should make
it into RTM. Further improvements to the UI can be done later.

verah: your text isn't quite correct:
- the dialog appears after pressing Reload, too
- the form is not "on this page", but on the previous page
- clicking Back or Forward will cause the dialog to appear

My suggestion for the text:

The page you are requesting was the result of submitting data in a form and may
have caused some additional action. Are you sure you want to re-submit the data
and perform that action again?

[Yes] [Cancel]
Non-super review r=adamlock. Patch looks fine to me.
Spoke to Verah about the wording. She is trying to come up with something
better, since the dialog would show up whenever the user uses
back/forward/reload/go menu and may not necessarily remember that he is going to
a page that has post data results. 
Okay, let's try this:

The page you are trying to view processes data you entered in an online form
(such as an order form or a membership application) earlier in this Netscape 6
session. If you view the page, the data will be re-submitted.

If you wish to re-submit the data, click Yes.

This patch looks good to me.  Post RTM we need to deal with bug #56346 which is 
why the page is not being cached :-)
PDT, we have the review and approval now.  It looks good.
Whiteboard: [rtm need info]Fix in hand. awaiting reviews → [rtm+]Fix in hand, reviewed and approved
Verah provided me with a slightly different wording on IM. Here's what she 
provided me..

The page you are trying to view processes data you entered in an online form
(such as an order form or a membership application) earlier in this Netscape 6
session. To view the page, re-submitting the data, click Yes. Otherwise, click 
PDT says rtm need info: Please attach dialog wording changes as a patch, need
msanz approval for them too.  Would take current patch without wording change.
Whiteboard: [rtm+]Fix in hand, reviewed and approved → [rtm need info]Fix in hand, reviewed and approved
PLEASE: Go Forward/Go Back should not have dialogs!! The user should see what 
they saw before in the history. That's the way 4.x works, and that's what makes 
sense, and is least complicated for users. Only Reload should ask to repost.
attached patch to the wording change. msanz please review it
please, do not change UI at this point. UI is frozen, for good. Is there a way
to resolve this without UI change? That would have to do it...
msanz, The UI change involves changing the wording for the dialog. The dialog 
was already there. It is just the wording that is different. The new wording 
makes the dialog more meaningful.  
I understand, but the new wording means new translation, and we are past that
I have to STORNGLY agree with msanz on this one. Either minus this bug, or just
take the patch without the new wording. The PDT is being very strict with us on
our delivery dates for language packs, so we need to be equally strict with any
suggested UI changes (i.e. No more UI changes that will cause us the go our for
more translations).
PDT, I would like to check this in with out the UI changes. Please provide a
approval. Also, are there any objections to checkin in to the trunk with the UI
This is probably a stupid question... but if this dialog has already been
translated, then why is it a problem to change the wording in the US version?
There would be no need to re-translate.
PDT says rtm++ for patch to docshell and nsSHistory.cpp to land on branch and
trunk, please land wording change only on trunk.
Whiteboard: [rtm need info]Fix in hand, reviewed and approved → [rtm++]Fix in hand, reviewed and approved
docshell and nsSHistory.cpp changes checked in to branch. 
docshell,nsSHistory.cpp+wording changechecked in to trunk.
Closed: 23 years ago
Resolution: --- → FIXED
back button now works, but forward still asks if you want to post. Hitting
Cancel doesn't load the cached page - instead nothing happens.
Resolution: FIXED → ---
forgot to mention my build id: linux comm MN6 build 2000101909.
jellwell, The behavior you observed is the workaround for the situation. Please 
see my comments  on 10-13-2000 14:08. Currently, mozilla does not cache post 
data results. So, it can not load the page from cache. (It will, once bug 56346 
is fixed) Earlier, pressing cancel used to load the page with GET and produce 
error messages. Now cancel does nothing (as requested in bug 53123)so that users 
can either surf elsewhere OR use the Go menu to go to some other page in 
history. Pressing forward will show up the dialog again, because the post data 
page  was not served by the previous back/forward operation. 

Marking fixed, so that QA can verify the workaround fix.
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Got another bug for the real fix? (Actually I think we should reopen this to 
keep the arguments intact.)
Note that the dialog mentions 'netscape 6' while I am not using Netscape 6. I am
using mozilla.

<insert rant about 'branded versions should be completely branded' here>
A minor point, but if you cancel the dialog, focus is not returned to the
browser window.  To reproduce: Alt-Left to back in history and get the dialog.
Hit ESC on the keyboard to cancel the dialog.  You now have to click in the
browser window before using the keyboard.  Other dialogs such as Find do not
have this problem.  Mozilla 101920 on NT4.
warren, I thought about keeping this bug open too. May be it can be reopened 
after claudius gets to confirm the fix. When it is reopened, all the rtm 
keywords should be removed. 
Sounds good. Let's reopen it and clear the fields when he's done.
I can VERIFY That the behavior is as coded in the 2000102008 branch build namely,

Submit a change to a bugzilla bug.
Click back.
See bug (with your comments stil in the text field, 'unsubmitted')
Click forward
See dialog:
Click yes, Reposts data, mid-air collision.
Click cancel, nothing happens.

So if i understand correctly I can't go forward because we don't cache the post data results.
That's great but what I really want to do is go forward w/o posting again. Why can't i do that?
Are we really gonna ship like this? Bug 56346 is not even confirmed much less plussed or anything.

Based on comments, I'd just reopen this now, but I want the verification to be in the bugs' history.
marking VERIFIED, do what you will.
Claudius, to answer your question,  in order to go forward with out re-posting
to the server, I need 56346 to be fixed. Re-opening and clearing rtm keywords as
discussed before. Leaving the ns601 keyword.
Keywords: rtm
Resolution: FIXED → ---
Whiteboard: [rtm++]Fix in hand, reviewed and approved
24 radha   1.5 repost=The page you are trying to view processes data you 
entered in an online form(such as an order form or a membership application) 
earlier in this Netscape 6 session. To view the page, re-submitting the data, 
click Yes. Otherwise, click Cancel.

Please do not use 'netscape 6' in the mozilla tree.

Also, 'a(this) that' might be ok in some functional languages but not English.

I'm told to CC don, don: you're CC. I'm adding a personal mozilla milestone 
target. However I've been told not to make this fix myself.
Keywords: mozilla0.9
*** Bug 57328 has been marked as a duplicate of this bug. ***
Quick note about this, along with saying Netscape 6, it also says "click Yes", 
but then gives you the options of "OK" or "Cancel", no "Yes."  These are the 
type of bugs that are really easy to fix, but make the product look bad.

CC'ing mpt cuz timeless told me to...
I know this dialog is only temporary, but if bug 56346 is not going to be fixed 
by RTM, then make your selection of which of the following smorgasbord of 
problems with it you want to fix.
1.  The title should be `Form Submission' (which is what the dialog is about),
    not `Confirm' (which means nothing).
2.  The icon should be the caution `!' icon (which indicates that the repost
    action is potentially dangerous), not the question `?' icon (which means
3.  The action button should read `Submit' (which is what it does), not `Ok'
    (which the situation isn't).
4.  The default button should be `Cancel' (which is safe), not `Submit' (which is
    potentially dangerous).
5.  The wording of the message should be changed to eliminate the inconsistency
    between the button name in the message and the button itself (which would get
    you a place in the User Interface Hall of Shame), to remove the mention of
    `Netscape 6' (which blocks bug 14532), to avoid unnecessarily technical (and
    possibly inaccurate) terminology such as `online' and `session', and
    generally to give the user a snowball's chance of understanding what's going
    on. I suggest:
    | "{page title}"
    | This page was generated as the result of a form submission, and
    | {browserName} does not have a cached copy of the page to display. If you
    | repost the form data, any action which the form carried out (such as a
    | search or an online purchase) will be repeated.
    | Do you want to submit the form again to see this page?

As Vera said, the fact that the wording of non-English versions won't be as clear 
as the English version is unfortunate, but that shouldn't hold back the English 
version from an improvement which doesn't affect the number or usage of the 
strings involved. (That's why I have the page title before the string itself, 
rather than as part of the sentence -- it's kind of tacky, but it avoids l10n 

Then bug 56346 should be fixed before the wrath of eBay users, Bugzilla users, 
and Web application users in general, raineth down upon thee like a torrent of 
fire and brimstone.
Blocks: 14532
Keywords: dataloss
Summary: Go Back broken for form post results. → Go Back broken for form post results
Couple of things:

We should not use these words and phrases: "repost" (not a word), "cached" (data
shows that users still don't know what this means) and "form submission" (this
sounds a bit techy; without testing I wouldn't use it). Also, we can't say "this
page" because that sounds like we're talking about the page the user is
currently viewing, which is not the one we're trying to communicate about.

I don't like the word "session," but we need to communicate that we're talking
about repeating something that happened recently. Since some actions that lead
to this dialog won't be what most people would consider submitting a form
(entering a username and password, for instance), when users read this they may
have to wrack their brains trying to figure out what "form" we're talking about.
I'd like to give them a fighting chance of figuring it out, by at least limiting
the time span that they have to think about.

Finally, the button names should match what we're telling them to click. If this
is impossible, then the text should be changed to refer to the buttons that are
actually in the dialog, even if we don't like their names. (However, my
understanding is that in this case the buttons names can be changed.)
I'll change the button names so that it matches the one in the text. Again these 
changes will go in to the trunk. 
verah: considering the comments on this dialog, should we request rtm?

I would.  Here's my assesment: the fix is low risk. Not fixing it results in a 
frequently viewed dialog which we all agree is confusing.

If you don't want to check the fix onto the branch might i suggest rolling back 
the change to some earlier incarnation? 

wrt fix, I'm sure blake or I would be willing to commit to branch if this bug 
did earn rtm++

mpt< and {browserName} does not have a cached copy of the page to display
Is that accurate, or is it actually:
   > and {browserName} does not keep a copy of dynamic web pages.
* Every previous version of Mozilla has considered `repost' to be a word -- but
  change it to `re-post' if you like.
* I used `cached copy' because the only alternative I could think of (`temporary
  copy') provided no clue as to why the browser would have been keeping a copy
  (or not) in the first place.
* I think `form submission' is less `techy' than `processes data', actually.
* If the page title is included in the dialog as I suggested, `this page' clearly
  refers to the page with the title given in the dialog, rather than the page
  shown in the browser window. Showing the title also largely solves the problem
  of the user wondering what form you're talking about, so `session' isn't

Timeless: Both are accurate -- the latter is more precise, but the former sounds 
more excusable. Take your pick. :-)
I seriously doubt if PDT will give it a rtm, since changes involve changing 
the language packs which have already been finalised. I believe lang-packs 
affect not just the foreign languages but also US-English.
Radha, that's right, wording changes are trunk-only.
> If you don't want to check the fix onto the branch might i suggest rolling 
back the change to some earlier incarnation? 

Please back this patch out.
There seems to be some duplication of effort here... bug 54492 is all about the
wording of this dialog box...
*** Bug 54492 has been marked as a duplicate of this bug. ***
Thanks jake, my apologies to all on that.  I suggest we use this bug for the 
development.  In the event the other bug is unduped and we roll this one back, 
that bug becomes invalid so i'm marking this bug as blocking bug 54492.

Yes I'm very sorry for messing up the separation but please don't undo the 
link, had it been in the bug when I came to it I wouldn't have dumped here.

Ben: although outsiders have offered to help the originators have not. cc 
brendan.  I think if i finish working on my maximize bug I might work on this 
one. *sigh*
Blocks: 54492
Although to my disappointment the wording change was not approved for checkin in
to the branch, I do not believe that the fix that was made for this bug in to
the branch should be rolled back.  I'm working on getting that "Netscape 6" out
of the wording in the dialog that was checked in to the trunk. I will be
checking in that after I attend to my rtm bugs.
Keywords: ns601
Clearing status whiteboard. Reopening the dupe, to track the separate issue. 
*** Bug 58649 has been marked as a duplicate of this bug. ***
This bug is IMO currently the worst bug in the browser. It renders Mozilla
useless for anything that forms were intended for. Many "forms" actually have
several steps, one on each page. It often happens that you notice you did
something wrong (or you just wanted to try out a value), and want to go back to
the last step. Now, if Mozilla reposts, it usually horks the session the server
keeps - you have to start all over. If you requested e.g. an account name,
sometimes, the account name is then "taken", and you have to find another one.

Note that this are no mode-up horror stories - I've encountered such problems
sevreal times. I guess you could indeed construct horror-stories where you
purchase twice or similar, if the server doesn't explicitly protect against that.

Personally, I think, this bug shouldn't make it into N6.0. I guess, it's too
late now, but adding rtm keyword anyway.
Keywords: rtm
relnote-user: don't press the back button after you submit a page; you'll 
regret it.  
Keywords: relnoteRTM
Whiteboard: relnote-user
Minusing this again.  We're not backing out the change.
Whiteboard: relnote-user → [rtm-]relnote-user
So, wait. Is this bug now not about the dialog box? My impression is that this 
is now about not having a dialog pop up at all when back is pushed (view from 
cache instead). And, if one wants to repost form data, reload should be pushed.

Someone confirm this?

If this is actually what I think it is, I suggest making this change for 
mozilla0.9 and the first bugfix release of N6.
I also thought that this bug was to make us do the right thing (at least as well
as 4.x did), not to pop up a clearer dialog about which variant of the wrong
thing we should do.  If not, then we need another bug on doing the right thing,
which seems silly -- why not just use this bug since it already has all the
comments in it on why this is important?

Though of course it's nice to have a clearer dialog until the real problem is fixed.
Keywords: 4xp
I agree. IMO, this dialog should go away *ASAP*. Please don't spend time
improving it, rather making it go away.
This bug is to come up with a real fix for the problem. I intend to keep it 
open for that purpose.
*** Bug 43123 has been marked as a duplicate of this bug. ***
Added self to CC.
*** Bug 52635 has been marked as a duplicate of this bug. ***
Please remove "Netscape 6" from the dialog... I was going to report a bug on it
before I discovered this bug, It's confusing and it's just a two words change.
IMHO this should be fixed ASAP even if the dialog is going to be removed latter.
We don't need even more people confused with the Mozilla/NS difference. Thanks.
The wording of the dialog is the subject of bug 54492.
Blocks: 60218
Adding cc to self 
Adding me to cc:
Removing myself from list of cc's.
nav triage team: yes we must fix this in the next release. 
Keywords: nsbeta1
Priority: P2 → P1
adding dep to 32293
Depends on: 32293
*** Bug 63570 has been marked as a duplicate of this bug. ***
*** Bug 64548 has been marked as a duplicate of this bug. ***
do we have an eta on this bug?
*** Bug 65021 has been marked as a duplicate of this bug. ***
i hope my extensive comments in (dupe) #65021 don't go to waste towards this

btw, thanks for responding quickly, you guys. you seem on the ball!
nav triage team:

Marking nsbeta1+
Whiteboard: [rtm-]relnote-user → [rtm-]relnote-user[nsbeta1+]
*** Bug 67189 has been marked as a duplicate of this bug. ***
*** Bug 57880 has been marked as a duplicate of this bug. ***
Any hope of getting this for Mozilla 0.8 instead of 0.9?  As someone said, this
is probably the worst bug in Mozilla/NS6 from a user perspective.  It is, after
all, P1, dataloss and nsbeta1+!

Is anyone actually working on this?
54346 needs to be fixed before the UI can be removed and SH can hook in to the
cache backend. unfortunately 54346 has not received any attention.
Sounds like you meant bug 56346. Also, this bug should not block 14532 or 54492
anymore, since the reference to N6 was removed.

I remember gagan or someone said that they were working on the cache backend,
and this also depended on that. Do we know of what progress they are making? I
would add gagan to cc, but I don't remember for sure that he was the one working
on the cache.
Doesn't [nsbeta1+] imply [nsbeta1+] for all blocking bug, too? Can anyone from
Netscape update the other bugs, please?
56346 (the bug this one depends on) is marked for mozilla 0.9. So, this one will
also be at the best mozilla 0.9 or later, depending on when exactly that gets fixed.
Target Milestone: --- → mozilla0.9
56346 has been marked dupe of 20843. Changing dependency.
Depends on: 20843
No longer depends on: 56346
IMHO this depends more on bug 40867 than on bug 20843, because if I understand
it correctly, bug 20843 is about cacheing the data sent to the server in the
POST request while bug 40867 is about cacheing the result of the request.

Adding dependency.
Depends on: 40867
adding imarsman, from bug 60218.
i would like to know why there isn't an option other than reloading and
cancelling - how about just viewing the cached HTML again? not having this
option makes repeatedly returning to a list of search results painful.
It *isn't* cached.
I don't know where the problems are, but they may be related to bug 69731.
Just tried this out on my banking site using build 2001022221. Asks me about
reposting. If I'm not mistaken, the build from two days before let me go back to
the cached version of this page. I may be incorrect. In any case, now if I try
to see my recent transactions, go to the "Next" page, then click the Back
button, the app I am connected to recognizes I have done this and makes me log
on again. The message is:
This page cannot be viewed with the method you've chosen. Please use the button
below to go to the sign on page (Ref. #R690).
I can navigate fine, as long as I remember to never use the NS buttons (Back,
Forward), just the links on the page. Choosing "view source" seems to re-request
the page and gives me this message and gets me in this state as well. I don't
think NS 4.7 re-requests the page on "view source".
> i would like to know why there isn't an option other than reloading and
> cancelling - how about just viewing the cached HTML again?

Because we don't have it anymore (at the moment). See the dependencies.
if this is only waiting on having all pages cached (bug 56346) then you can 
safely mark it dep/dup. 56346 should land by 0.9
Hardware: All → DEC
Please don't mark it dupe. After 56346 lands, there is some work in Docshell to
fix this completely.
Platform->All again (gagan set it to DEC)
Hardware: DEC → All
Added dependency per radha's comment on 56346
Depends on: 56346
*** Bug 72306 has been marked as a duplicate of this bug. ***
*** Bug 72684 has been marked as a duplicate of this bug. ***
*** Bug 72802 has been marked as a duplicate of this bug. ***
Depends on: 72520
No longer depends on: 56346
*** Bug 50391 has been marked as a duplicate of this bug. ***
I have attached a patch that uses the features in the new cache to obtain post 
data results from cache when the user goes back/forward to it.  Now the 
dialog won't come up every time the user goes back/forward to a postdata 
result. The dialog will come up, *only* if the cache entry for the post result 
has expired from cache.  It is not clear to me when a post data result would 
expire from cache. I used some rudimentary methods to test that part of code. 
unfortunately prefs is not hooked up to the new cache yet. I'm not *very happy* 
with  throwing a dialog whenever a post result expires from cache.  There are 
some  misbehaviors in the back and forward button when the dialog comes up. I'm 
experimenting the idea of showing a intermediate page like Nav 4.7, instead of a 
dialog. Shall post details of that when I'm convinced it works well reasonably
Code looks good apart from a few small nits:

1. DEBUG_Radha
2. does not end with a newline

I ran Radha's patch on Linux, and did a few tests on a shopping site, comparing
the behavior with a pre-patched version. The patch seems to have fixed this bug.
For me, this bug is one of the most annoying "features" in Mozilla and I've been
longing for a long time for it to be fixed. So, please try to get this into the
trunk before 0.9.
looks good... sr=rpotts

fix checked in
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Depends on: 90722
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).


[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
No longer blocks: 60218
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.