Closed
Bug 43123
Opened 24 years ago
Closed 24 years ago
`repost form data?' dialog has poorly named buttons
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
People
(Reporter: fosterd, Assigned: radha)
References
Details
The `repost form data?' dialog (for example, when you click the back button to
return to a POST-generated page) has buttons labeled `OK' and `Cancel'. This is
misleading as `Cancel' implies not loading the page at all; they should be
labeled `Yes' and `No'.
Comment 1•24 years ago
|
||
But `Cancel' *is* not loading the page at all. If the page is in the cache, then
you shouldn't get this dialog anyway, unless you choose Reload.
`Yes' and `No' are just as bad as `Ok' and `Cancel', because `Would you like to
continue without reposting the form data?' would use exactly the same buttons
with exactly the opposite effect.
Seamonkey convention is to use a meaningful verb for the main action button. I
suggest `Repost' and `Cancel'.
Reporter | ||
Comment 2•24 years ago
|
||
Sorry for being unclear. What I meant by "not loading the page" was "not
displaying it on the screen; not taking any action at all", as opposed to "not
fetching the page again from the network."
Comment 3•24 years ago
|
||
Decklin is right -- pressing 'cancel' does not actually cancel the action. It
merely continues without posting form data, opening the door for some potentially
ugly results. However, if cancel *did* cancel and leave you at the original
starting page, users would be stranded. They'd click 'back' again and be faced
with the same dialog. The advantage to the current behavior is it still
navigates the history, meaning that users can continue navigating without
reposting form data and without having to know about or use the history menu.
Therefore, I recommend following Decklin's suggestion and changing the text
labels to 'Yes' and 'No.'
Assignee: bdonohoe → rods
Component: User Interface: Design Feedback → Form Submission
QA Contact: mpt → ckritzer
Comment 4•24 years ago
|
||
Ok, that makes sense. As a side issue, if `No' refetches the URL but without
reposting the form data, that's a different bug -- it should be doing the 4xp
thing and showing a placeholder page (a la bug 28586) telling the user that the
data wasn't reposted.
Comment 5•24 years ago
|
||
Eric, this may not be yours, but you will know who to send it to.
Assignee: rods → pollmann
Comment 6•24 years ago
|
||
Radha, this seems like a session history/webshell thing. Can you take a look?
Thanks!
Assignee: pollmann → radha
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M23
Comment 8•24 years ago
|
||
I have another suggestion for a solution to this bug, which may or may not make
sense to non-power-users (comments?):
- "Yes": repost form data, go to page in question
- "No": go to page in question without reposting form data (current "Cancel"
behavior)
- "Cancel": don't do anything
The "Yes"/"No"/"Cancel" triad is not without precedent, but I can't think of
other examples right now.
I'd like to voice support for Matt's suggestion of three buttons.
The current behaviour of "cancel" doesn't actually cancel the quested
action (traversal up the browser history chain). This confused me
the first time I decided not to repost form-data...I expected to remain
on the same page. To me, "No" would imply: "show me the page as it was
rendered from the _previous_ post"...there are situations where one would
want to do this.
Assignee | ||
Comment 10•24 years ago
|
||
I like the 3 button idea too. I need to look a little deeper to get that going.
I will do that after taking care of my beta3 list.
Comment 11•24 years ago
|
||
Note that the Cancel button currently is broken by bug 46338 and causes a
HTTP GET on the page in question.
I like the 3 button idea too, but "No" should not continue the broken "Cancel"
behaviour. It should fetch the page from cache. If it's not in cache for some
reason, the dialog should not present the "No" button.
If present, the "No" button should be the default button. "OK" / "Yes" can have
side effects like buying the same thing twice.
Comment 12•24 years ago
|
||
I'll second Clarence's notion ... going back to the site with GET makes no
sense whatsoever and would be confusing to users.
Also, given that this bug and bug 46338 are pretty much identical, I think this
should either be marked nsbeta3+ or duplicate of that one. And frankly, the
comments here are clearer on what is going on, so I think that one should be a
duplicate of *this* one.
Here is a URL to a testcase I created in bug 47924:
http://www.ieffects.com:8080/cgi-bin/mozbug1.pl. Go to the URL, click Submit.
Yo yo man appears. Reload. Hit Cancel on the "repost form data?" dialog. Yo
yo man disappears because it has gone back to the server with a GET, losing the
hidden parameter.
Comment 13•24 years ago
|
||
To make the message make sense, we could add something to the effect of:
"Pressing 'yes' may cause the action you performed by loading the page to be
done a second time."
This addition makes slightly more sense if you get the warning after pressing
reload on a placeholder page (as opposed to pressing on the page after the page
that was posted to).
Comment 14•24 years ago
|
||
Forgive me if the following has already been addressed, but: I'm almost centain
that I'd rather have the back-button NEVER result in a network transaction. I'd
like a preference so that I need not be bothered with this dialogue box at all.
If reposting is what I want, I'd submit the form after going back. Can we make a
preference so that the back button merely redisplays the previous HTML, as was
the case in Navigator 4.x?
Comment 15•24 years ago
|
||
...so long as the page is in the cache, of course.
Comment 16•24 years ago
|
||
Comments from bug 47924 by John Keiser:
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m17) Gecko/20000804
BuildID: 2000080404
When you click refresh on a POST form, the dialog box has "Cancel" on it but
when you click Cancel it still goes back to the server with a GET response.
Cancel implies to me (and probably many others) that the operation will not
proceed; something more like Yes / No / Cancel or even just Yes / No would be
more appropriate in this case.
And steps to repro:
1) Launch browser
2) Load http://www.ieffects.com:8080/cgi-bin/mozbug1.pl
2a) A page loads with only a 'submit' button on it
3) Click on 'submit' button
3a) A security alert dialog comes up.
4) Click 'OK' button on security warning
4a) A second page loads with 'Yo yo man' in H1 and a 'submit' button below it
5) Click on the 'Refresh' button at top of window
6) Click 'Cancel' button on security warning
Comment 17•24 years ago
|
||
*** Bug 47924 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
See my comments in bug 46338.
Comment 19•24 years ago
|
||
pohl: The 4.x behaviour you described occures only if the result of the post is
a HTTP 3xx response. Now Mozilla behaves so too (see bug 46338).
Comment 21•24 years ago
|
||
pohl: I agree. I find it really annoying that it pops up all the time. It
would be good to be able to set a default action as a preference which could be
over ridden. I know when using IE I never get prompted to repost. This is
especially annoying when using on-line systems that require a lot of back and
forwards - it really impacts your speed in using such a system.
Comment 22•24 years ago
|
||
I have to revise my previous opinion:
We should not present a dialog at all in this situation. Instead we should
always present the old result of the POST, even if it's not cachable (are we
able to do this now?). A way to notify the user that the contents of the page
are stale would be a message in the status bar. If a user wants to repost the
data, he/she can go back to the form and submit it again or click reload (in
the latter case a warning would be appropriate).
RFC 2616 (HTTP/1.1) says (and I agree):
--8<----
13.13 History Lists
User agents often have history mechanisms, such as "Back" buttons and
history lists, which can be used to redisplay an entity retrieved
earlier in a session.
History mechanisms and caches are different. In particular history
mechanisms SHOULD NOT try to show a semantically transparent view of
the current state of a resource. Rather, a history mechanism is meant
to show exactly what the user saw at the time when the resource was
retrieved.
By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism SHOULD display
it even if the entity has expired, unless the user has specifically
configured the agent to refresh expired history documents.
This is not to be construed to prohibit the history mechanism from
telling the user that a view might be stale.
Note: if history list mechanisms unnecessarily prevent users from
viewing stale resources, this will tend to force service authors
to avoid using HTTP expiration controls and cache controls when
they would otherwise like to. Service authors may consider it
important that users not be presented with error messages or
warning messages when they use navigation controls (such as BACK)
to view previously fetched resources. Even though sometimes such
resources ought not to cached, or ought to expire quickly, user
interface considerations may force service authors to resort to
other means of preventing caching (e.g. "once-only" URLs) in order
not to suffer the effects of improperly functioning history
mechanisms.
--8<----
Comment 23•24 years ago
|
||
Discussion seems to have moved to bug 55055.
Assignee | ||
Comment 24•24 years ago
|
||
Post RTM work. This dialog is going to go away. Markign this a dupe of 55055
which currently tracts the reposting problem.
*** This bug has been marked as a duplicate of 55055 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•