155050 - form submission state not totally retained when back button is clicked

Status: VERIFIED DUPLICATE of bug 38486

(Core :: DOM: Core & HTML, defect, P4)

Description

[Brian Tarricone]

ok, i guess i'll start by describing a scenario.

you have a form that has several radio button options, and there are other
<input> items that are enabled/disabled (via javascript) depending on which
radio button is selected.  some of the items are disabled by default when you
request the page (via <input name=blah value=blah disabled>).  a user enters
some data, changing the radio button values (and thus causing different items to
be enabled/disabled than the default).  the user clicks submit, but there is
some error, so the user clicks the back button in the browser to go back to the
form.

here's the problem.  the radio buttons retain their previous state - if the user
changed them before they clicked submit, the back button will keep them in the
new state (i.e. not the default from what would happen just by visiting the
page).  however, the items that were enabled/disabled via javascript are
"incorrect" - that is, they have returned to the page's default state (via
<input ... disabled>).  this means that the user has to click on a different
radio button, then back to the one they selected, to reenable the form options
that they had previously been using.

argh, this sounds horribly complex.  i'll try to work up a simple testcase.

anyway here's what i think needs to be done.  either a) all form items are
returned to their default when the back button is pressed, or b) the "onchange"
or "onclick" signals must be called on all form items.

i think (a) is a really bad idea (who else among us have filled out a really
long form, only to click submit, and have an error, then click back only to find
the entire form has reset - ugh).  but (b) also has issues as well.

thoughts?

Comment 1

[Brian Tarricone]

ok, i made up a quick testcase:
<http://kelnos.dynodns.net/testing/form_hist_test.html>

here's what to do:
1) click 'radio choice 2' - note that 'checkbox 1' gets disabled, and 'checkbox
2' gets enabled.  check the checkbox if you want, doesn't matter.
2) click submit.  you get an error (i obviously didn't bother creating a cgi
script for it, but the behaviour is identical with one, so...)
3) click the browser's back button.
4) you're returned to the page.  'radio choice 2' is still selected, but
'checkbox 2' is now disabled, and 'checkbox 1' is enabled.
5) to fix this, you have to click back on radio 1, and then back to radio 2.

this doesn't seem like proper behaviour to me.  perhaps i'm just a poor
javascript coder and there's a better way of achieving what i want.  if so, feel
free to flame me ^_~

Comment 2

[Boris Zbarsky [:bzbarsky]]

here ya go, jkeiser. ;)

Comment 3

[Jesse Ruderman]

Possible fixes:
1. Remember whether each form element was enabled.
2. Trigger onchange events while restoring form state.
3. Keep the entire state of pages in session history, like Opera does (bug 38486).

Comment 4

[Vladimir Ermakov]

confirming

Comment 5

[John Keiser (jkeiser)]

(1) remembering whether form elements are enabled gets us on a slippery slope to
remembering everything JavaScript ever changes.  For example, the set of options
that are in a select.  If we go this route we ought to just do (3).

The fundamental problem is that we should restore everything or nothing.  This
half-assed "let's restore a few things" causes all sorts of problems.

(2) triggering onChange is highly likely to break lots of pages, especially
navigation pages that had a <select> that did document.location = "..." onChange.

(3) bug 38486, as you say.

NEW OPTION:
(4) as a page author, you can add the attribute autocomplete="off" to those
radio buttons and they will not be restored.

Unless there is some other way around the problem, I suspect we're going the
WONTFIX or "dup of bug 38486" route.

Comment 6

[Brian Tarricone]

i would hope no WONTFIX here - this is clearly (to me at least) something that
needs to be addressed.  possibly a dupe of bug 38486, but i really feel that the
current "remembering" of form elements is sloppy at best.  why remember which
radio button was selected if you aren't going to remember the
disabled/readonly/etc state of a form element?  i think an all-or-nothing
approach needs to be taken here.

as for autocomplete="off" - is that a w3c standard?  i can't seem to find it
anywhere in the html 4.0 spec (granted i didn't look to hard).  i think it's
foolish to try to add proprietary extensions here (*cough*microsoft*cough*).

honestly, i'd rather all support for remembering form elements to be removed
than to have only part of the state data kept, regardless of the implications in
memory usage, performance, etc. - if opera can do it (and fast, as it seems),
mozilla can too.  i'm willing to concede that this is a dupe of bug 38486 in
that regard...

Comment 7

[John Keiser (jkeiser)]

> why remember which radio button was selected if you aren't going to remember the
> disabled/readonly/etc state of a form element?  i think an all-or-nothing
> approach needs to be taken here.

Exactly.  Unfortunately the "none" option is gone, though it's the approach I'd
prefer.  We can't do it, people are used to it, it's just too late.  The "all"
approach is bug 38486.

Our current half-assed behavior is "save and restore all things that are
directly modified by the user."  This covers enough pages to make things useful.

Resolving duplicate.

*** This bug has been marked as a duplicate of 38486 ***

Comment 8

[Vladimir Ermakov]

verifying duplicate