Closed
Bug 55055
Opened 24 years ago
Closed 24 years ago
Go Back broken for form post results
Categories
(Core :: DOM: Navigation, defect, P1)
Core
DOM: Navigation
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: warrensomebody, Assigned: radha)
References
Details
(Keywords: dataloss, Whiteboard: [rtm-]relnote-user[nsbeta1+])
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 2•24 years ago
|
||
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 amazon.com'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]
Assignee | ||
Comment 4•24 years ago
|
||
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.
Reporter | ||
Comment 5•24 years ago
|
||
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
Comment 7•24 years ago
|
||
Adding Michele and Monste to cc: list.
I would vote for getting these changes into RTM. People use the back button
"alot".
Comment 9•24 years ago
|
||
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.
Reporter | ||
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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-]
Assignee | ||
Comment 13•24 years ago
|
||
I'm working on a fix as I type this. Please hold on..
Assignee | ||
Comment 14•24 years ago
|
||
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.
Assignee | ||
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
Restoring need info. Radha, get the fix and the reviews ASAP!
Whiteboard: [rtm-] → [rtm need info]
Comment 17•24 years ago
|
||
> 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.
Assignee | ||
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
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
Comment 20•24 years ago
|
||
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:
DATA MISSING
This page is the result of a form post and cannot be displayed at this time.
Assignee | ||
Comment 21•24 years ago
|
||
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.
Assignee | ||
Comment 22•24 years ago
|
||
Assignee | ||
Comment 23•24 years ago
|
||
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
Comment 24•24 years ago
|
||
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]
"
Assignee | ||
Updated•24 years ago
|
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
Reporter | ||
Comment 25•24 years ago
|
||
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.
Comment 26•24 years ago
|
||
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]
"
Comment 27•24 years ago
|
||
Non-super review r=adamlock. Patch looks fine to me.
Assignee | ||
Comment 28•24 years ago
|
||
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.
Comment 29•24 years ago
|
||
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.
"
Comment 30•24 years ago
|
||
sr=rpotts
This patch looks good to me. Post RTM we need to deal with bug #56346 which is
why the page is not being cached :-)
Comment 31•24 years ago
|
||
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
Assignee | ||
Comment 32•24 years ago
|
||
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
Cancel.
Comment 33•24 years ago
|
||
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
Reporter | ||
Comment 34•24 years ago
|
||
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.
Assignee | ||
Comment 35•24 years ago
|
||
Assignee | ||
Comment 36•24 years ago
|
||
attached patch to the wording change. msanz please review it
Comment 37•24 years ago
|
||
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...
Assignee | ||
Comment 38•24 years ago
|
||
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.
Comment 39•24 years ago
|
||
I understand, but the new wording means new translation, and we are past that
deadline.
Comment 40•24 years ago
|
||
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).
Assignee | ||
Comment 41•24 years ago
|
||
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
change?
Comment 42•24 years ago
|
||
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.
Comment 43•24 years ago
|
||
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
Assignee | ||
Comment 44•24 years ago
|
||
docshell and nsSHistory.cpp changes checked in to branch.
docshell,nsSHistory.cpp+wording changechecked in to trunk.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 45•24 years ago
|
||
back button now works, but forward still asks if you want to post. Hitting
Cancel doesn't load the cached page - instead nothing happens.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 46•24 years ago
|
||
forgot to mention my build id: linux comm MN6 build 2000101909.
Assignee | ||
Comment 47•24 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 48•24 years ago
|
||
Got another bug for the real fix? (Actually I think we should reopen this to
keep the arguments intact.)
Comment 49•24 years ago
|
||
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>
Comment 50•24 years ago
|
||
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.
Assignee | ||
Comment 51•24 years ago
|
||
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.
Reporter | ||
Comment 52•24 years ago
|
||
Sounds good. Let's reopen it and clear the fields when he's done.
Comment 53•24 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 54•24 years ago
|
||
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.
Status: VERIFIED → REOPENED
Keywords: rtm
Resolution: FIXED → ---
Whiteboard: [rtm++]Fix in hand, reviewed and approved
Comment 55•24 years ago
|
||
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
Whiteboard: [NETSCAPE CODE IN MOZILLA TREE]
Comment 56•24 years ago
|
||
*** Bug 57328 has been marked as a duplicate of this bug. ***
Comment 57•24 years ago
|
||
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...
Comment 58•24 years ago
|
||
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
nothing).
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
problems.)
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.
Comment 59•24 years ago
|
||
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.)
Assignee | ||
Comment 60•24 years ago
|
||
I'll change the button names so that it matches the one in the text. Again these
changes will go in to the trunk.
Comment 61•24 years ago
|
||
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.
Comment 62•24 years ago
|
||
Vera:
* 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
necessary.
Timeless: Both are accurate -- the latter is more precise, but the former sounds
more excusable. Take your pick. :-)
Assignee | ||
Comment 63•24 years ago
|
||
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.
Comment 64•24 years ago
|
||
Radha, that's right, wording changes are trunk-only.
Comment 65•24 years ago
|
||
> 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.
Whiteboard: [NETSCAPE CODE IN MOZILLA TREE] → [NETSCAPE CODE IN MOZILLA TREE][REQUEST ROLLBACK]
Comment 66•24 years ago
|
||
There seems to be some duplication of effort here... bug 54492 is all about the
wording of this dialog box...
Comment 67•24 years ago
|
||
*** Bug 54492 has been marked as a duplicate of this bug. ***
Comment 68•24 years ago
|
||
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
Status: REOPENED → NEW
Assignee | ||
Comment 69•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Comment 70•24 years ago
|
||
Clearing status whiteboard. Reopening the dupe, to track the separate issue.
Whiteboard: [NETSCAPE CODE IN MOZILLA TREE][REQUEST ROLLBACK]
Assignee | ||
Comment 71•24 years ago
|
||
*** Bug 58649 has been marked as a duplicate of this bug. ***
Comment 72•24 years ago
|
||
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
Comment 73•24 years ago
|
||
relnote-user: don't press the back button after you submit a page; you'll
regret it.
Keywords: relnoteRTM
Whiteboard: relnote-user
Comment 74•24 years ago
|
||
Minusing this again. We're not backing out the change.
Whiteboard: relnote-user → [rtm-]relnote-user
Comment 75•24 years ago
|
||
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.
Comment 76•24 years ago
|
||
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
Comment 77•24 years ago
|
||
I agree. IMO, this dialog should go away *ASAP*. Please don't spend time
improving it, rather making it go away.
Assignee | ||
Comment 78•24 years ago
|
||
This bug is to come up with a real fix for the problem. I intend to keep it
open for that purpose.
Assignee | ||
Comment 79•24 years ago
|
||
*** Bug 43123 has been marked as a duplicate of this bug. ***
Comment 80•24 years ago
|
||
Added self to CC.
Comment 81•24 years ago
|
||
*** Bug 52635 has been marked as a duplicate of this bug. ***
Comment 82•24 years ago
|
||
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.
Comment 83•24 years ago
|
||
The wording of the dialog is the subject of bug 54492.
Comment 84•24 years ago
|
||
Adding cc to self
Comment 85•24 years ago
|
||
Adding me to cc:
Comment 86•24 years ago
|
||
Removing myself from list of cc's.
Comment 87•24 years ago
|
||
nav triage team: yes we must fix this in the next release.
Keywords: nsbeta1
Priority: P2 → P1
Comment 89•24 years ago
|
||
*** Bug 63570 has been marked as a duplicate of this bug. ***
Comment 90•24 years ago
|
||
*** Bug 64548 has been marked as a duplicate of this bug. ***
Comment 91•24 years ago
|
||
do we have an eta on this bug?
Comment 92•24 years ago
|
||
*** Bug 65021 has been marked as a duplicate of this bug. ***
Comment 93•24 years ago
|
||
i hope my extensive comments in (dupe) #65021 don't go to waste towards this
discussion.
btw, thanks for responding quickly, you guys. you seem on the ball!
Comment 94•24 years ago
|
||
nav triage team:
Marking nsbeta1+
Whiteboard: [rtm-]relnote-user → [rtm-]relnote-user[nsbeta1+]
Comment 95•24 years ago
|
||
*** Bug 67189 has been marked as a duplicate of this bug. ***
Comment 96•24 years ago
|
||
*** Bug 57880 has been marked as a duplicate of this bug. ***
Comment 97•24 years ago
|
||
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?
Assignee | ||
Comment 98•24 years ago
|
||
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.
Comment 99•24 years ago
|
||
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.
Comment 100•24 years ago
|
||
Doesn't [nsbeta1+] imply [nsbeta1+] for all blocking bug, too? Can anyone from
Netscape update the other bugs, please?
Assignee | ||
Comment 101•24 years ago
|
||
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
Assignee | ||
Comment 102•24 years ago
|
||
56346 has been marked dupe of 20843. Changing dependency.
Comment 103•24 years ago
|
||
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
Comment 104•24 years ago
|
||
adding imarsman, from bug 60218.
Comment 105•24 years ago
|
||
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.
Comment 106•24 years ago
|
||
It *isn't* cached.
I don't know where the problems are, but they may be related to bug 69731.
Comment 107•24 years ago
|
||
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".
Comment 108•24 years ago
|
||
> 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.
Comment 109•24 years ago
|
||
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
Assignee | ||
Comment 110•24 years ago
|
||
Please don't mark it dupe. After 56346 lands, there is some work in Docshell to
fix this completely.
Comment 113•24 years ago
|
||
*** Bug 72306 has been marked as a duplicate of this bug. ***
Comment 114•24 years ago
|
||
*** Bug 72684 has been marked as a duplicate of this bug. ***
Comment 115•24 years ago
|
||
*** Bug 72802 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Assignee | ||
Comment 116•24 years ago
|
||
*** Bug 50391 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 117•24 years ago
|
||
Assignee | ||
Comment 118•24 years ago
|
||
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
Assignee | ||
Comment 119•24 years ago
|
||
Comment 120•24 years ago
|
||
Code looks good apart from a few small nits:
1. DEBUG_Radha
2. appstrings.properties does not end with a newline
r=adamlock
Comment 121•24 years ago
|
||
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.
Comment 122•24 years ago
|
||
looks good... sr=rpotts
Assignee | ||
Comment 123•24 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 124•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
•