Closed Bug 46845 Opened 24 years ago Closed 19 years ago

Form elements don't reset upon manually reloading page

Categories

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

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED INVALID
Milestone:
Future

People

(Reporter: bugzilla, Assigned: radha)

References

(Blocks 2 open bugs,
URL
)

Details

(5 keywords, Whiteboard: relnote-user) 

Build ID: 2000072808 WinNT4 M18

Steps to Reproduce:

(1) Go to any page with a textbox or a textarea (e.g. the URL given)
(2) Type in the textfield.
(3) Reload the page.

Result:  The text doesn't clear from the textfield...this means that the user
has no real way to clear any information he/she has entered except by manually
erasing it.
prob a dup, can't find
Keywords: correctness, nsbeta3
nav triage team:
although not in parity with 4.x, not good enough to warrant an nsbeta3+
Whiteboard: [nsbeta3-]
Need to change nsDocShell::embed() so that Layouthistorystate is restored only 
when the reload is "loadNormalReload". If it is anything else like 
ReloadBypassCache OR RelaodBypassCacheAndProxy, then we should not restore form 
values.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
Target Milestone: M19 → M18
*** Bug 51079 has been marked as a duplicate of this bug. ***
transferring dogfood+ status from bug 51079 (methinks we need to be a bit more 
consistent in our plussing/minusing...this gets nsbeta3- but its dup got 
dogfood+?)
Keywords: dogfood
Whiteboard: [nsbeta3-] → [nsbeta3-] [dogfood+]
dogfood is a bit of a wildcard sometimes.  It helps to have an exact case to
compare the effects.
Priority: P3 → P1
I'm a little confused as how this should behave. In 4.x, if you go to the main 
bugzilla page and enter a bug # and press reload, the bug # is still there, 
shift-relaod clears the bug #. However, in  the bugzila query page, enter values 
in couple of text fields to query for a bug, press reload, the text fields 
clear. The only difference I could think off between these 2 pages is that, the 
first one uses "GET", where as the extensive query page uses "POST".  

In mozilla, I'm planning on clearing the text fields for reload as well as 
shift-reload. Anybody have problems with that?
Hmm..that's a good question.  I really don't know.  Matthew/Claudius: any idea?
I just checked and IE 5 retains form values when pressing reload or shift+reload
(unless you do it over and over again really fast, then after five or so times,
presto, your form values disappear).

Also, both Nav and IE retain the scroll position when pressing reload.  Nav does
this even when clearing out form values with shift+reload.  If we decide to do
this, could add a boolean flag to presShell::SetHistoryState() like
aOnlyRestoreScroll that would be only true for shift+reload or something like
that...

I'm not sure that, given Nav and IE's behaviour, a user or a web designer would
expect the forms to be cleared out when a user presses reload.  A web designer
always has the option of adding a <INPUT TYPE=RESET> or calling form.reset()
through javascript if they want the form to reset...
This is not the behavior I see at all in win32 IE5.5.

Note, however, that by this bug I mean that only changes the user makes to 
textboxes should be cleared on reload.  For example, if the default text value 
of a textbox is "hello" and the user types " bob" after it, the textbox should 
refer back to "hello" if the user reloads -- just as if you had pressed a reset 
button.
Eric, how tough is adding that parameter to PResShell::SetHistoryState()? To 
answer blake ross's question, if the text field had a default value, it will get 
set again when we reload the page. I don't believe, SetHistoryState() meddles 
with default values set by the page.
Eric, I agree with your email comments. I'm actually OK with retaining values 
upon reload and clearing values upon shift-reload. I was quite puzzled to see 
Nav clear form fields on reload. 
Blake, Johnny Stenback and I just tested this out because we saw something
different than you.  In IE 5.0 and IE 5.5, the behaviour is to retain form
values if the reload comes from the cache (e.g. http://bugzilla.mozilla.org,
type a bug number and hit reload) but NOT retain the form values if the reload
hits the server (e.g. hotmail, while composing a lengthy email, accidentally hit
reload and your message is blanked).

I tend to think that there is more of a chance that a user will be mad to see
their half-hour of work destroyed in one accidental mouse click than having to
manually select the field to retype it.  If we do make the blanking-on-reload
behaviour available, it should probably be through a pref that defaults to off. 
Also note, that web designers can (and have always been able to) add <INPUT
TYPE=RESET> to a page to add a button that resets a form in a single click.
> Eric, how tough is adding that parameter to PresShell::SetHistoryState()?

If we did decide to emulate Nav's behaviour, it shouldn't be too bad...  We
would have to change all callsites (3?), add the param to
PresShell::SetHistoryState and nsWebShell::SetHistoryState.  We would probably
use the param in PresShell::ContentAppended to *not* call
mFrameManager->RestoreFrameState, but probably just always continue to restore
the scrollbar state in PresShell::EndLoad
I don't think this is primarily about web developers.  I think it's about what
users want from their browser.  I think the best path here is to leave the
values on a reload, but clear them on shift-reload.  IMHO, the IE behavior is
also a bug.  The cache shouldn't really have anything to do with this from a
user's point of view since then it would just look random.

Requiring the shift with the reload covers the "accidental" loss of data argument.
Do we all agree that reload maintains form values, shift-reload clears. I like 
it. Eric, if you are busy, I can take care of adding the new parameter to 
nsPresShell::SetHistoryState(). Changes to docshell will be minimal too.
If I select Reload, I expect a fresh copy of the document -- one where the 
contents of form elements, just like the contents of the rest of the page, are as 
the author/server specified them, and not as I specified them. To leave values I 
entered in the form on a reload makes no sense -- especially since some or all of 
the form elements may change, may take on different meanings, or may no longer 
exist, when the document is reloaded.

See also Jakob Nielsen, who suggests that `Reset' buttons should not be included 
on Web forms <http://www.useit.com/alertbox/20000416.html> (and I agree). This 
would leave the `Reload' function as the way of clearing the contents of a form, 
if you really wanted to do so. He also says: `A classic design mistake on the Web 
is to have radio buttons that initially do not have a selection. Often, there is 
no way for the user to select a "nothing" option, once he or she has selected one 
of the choices.' There is one way: the Reload button ... as long as this bug is 
fixed, of course.
Keywords: 4xp
Matthew, what about the "data loss" argument?
If I change a whole lot of prefs in the prefs dialog, and then I click `Cancel', 
I lose all those changes. That's what `Cancel' is for. It's data loss, but it's
*supposed* to be data loss. We don't have a warning dialog popping up saying `Are 
you sure you want to exit prefs?', because we trust the user to know what they're 
doing.

Similarly, when I fill out stuff in a Web form (which is just a glorified dialog, 
really), and then I click `Reload', I *expect* all my changes to be cleared. If 
that doesn't work, many users will see no method of clearing the form short of 
restarting the browser -- or using a different browser.

Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
just so everyone is clear, this has been implemented such that 'Reload' just 
fetches the page, maintaing the form fields' status. 'Shift'+'Reload' clears the 
form fields.

I have verified this behavior with the 2000091908 builds, marking VERIFIED 
Fixed.
Status: RESOLVED → VERIFIED
Shouldn't that be verified wontfix, then?
Reopening.  I think this is an absolutely terrible way to fix this bug.  

First of all, why should users need to have the navigation toolbar open all the 
time?  Shift+Ctrl+R, Shift+F5, Shift+View>Reload, and Shift+Context Menu>Reload 
all just reload from the cache and ignore the shift modifier.  This means that 
anyone that wants this behavior needs to have the navigation toolbar 
open/uncollapsed, and needs to use it.

Second, when people are using the mouse to surf, who wants to switch to the 
keyboard and hold down a modifier just to get the standard behavior to happen?  
Non-standard behavior should be triggered by hidden modifier shortcuts; the 
user should not have to work to get the behavior he expects, it should just 
happen by default.

Third, seeing as how it seems to be an easy fix just to fix it the `right' way, 
why are we going out of the way just to change the typical behavior of the 
Reload button?  The Reload button has functioned this way for as long as I can 
remember.  If users have been accustomed to it for years, and there doesn't 
seem to have been many complaints, why should we change it?

Fourth, the data loss argument is a silly one.  There are times when the user 
wants to voluntarily lose data; we should not be overeager in protecting him or 
her from such cases.  If a user is typing in a form, they are not likely to 
accidentally going to click Reload.  Again, if Reload has worked like this 
forever, where are the complaints from users that suggest we should change this?

Let's fix this the right way.  If users start complaining, we can change it.  
After all, things should really only change from the standard if user input 
suggests that they should.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: Contents of textboxes/textareas don't clear upon reloading page → Form elements don't reset upon reloading page
By the way, this applies to all form elements -- not just textfields.  Also, 
this used to work, but regressed.
Keywords: regression
Add to all the points above, two further problems. Firstly,
Shift+{click-Reload-button} is not documented anywhere. Secondly, it's not 
accessible for people who can only use the keyboard -- and even if Shift+Ctrl+R 
was implemented, that would be hard for people who have difficulty pressing more 
than two keys at once.
Keywords: access
These are good things to debate for future fixes.  Changing this again won't get
approved right now.  Removing dogfood+ because this bug is now complaining about
the fix rather than the original problem.
Whiteboard: [nsbeta3-] [dogfood+] → [nsbeta3-]
I agree that this shouldn't be dogfood+, and never should have been.  But this 
bug is still complaining about the original problem, because the original 
problem was to reset form elements upon pressing reload -- and that still 
doesn't happen.  You can fix a bug a thousand different ways, but not all of 
them are right... (-Blake 9/2000)

There's no need for this to be futured off.  I can make the change and check it 
in without it having to be a P1/pdt+ bug.  So, let's make a decision and I'll 
do it.
Keywords: dogfood
Removing nsbeta3- to trigger a decision, since we have a volunteer. (Attaboy, 
Blake ...)
Whiteboard: [nsbeta3-]
Restoring "nsbeta3-".

I agree with Radha and others that we should not, by default, clear form data on
reload.  I realize that the shift-reload solution to override this may not be
optimal.  However, sometime after sufficient user feedback, we can add an
explicit command or even a visible preference, if necessary, to do this.

I'm adding the "relnote3" keyword to this bug so Vera can mention the changed
behavior in the release notes.
Keywords: relnote3
Whiteboard: [nsbeta3-]
Radha asked for some comments from PDT... so I thought I'd add my comments:

I just tried this on Nav 4.7.  What I saw (my test page was
bugzilla.mozilla.org) was that reload maintained the data entered, and shift
reload reset the fields.
As a result, this seems to be exactly the same as Claudius verified the
performance on 9/19

I also verified that IF you get focus on the URL bar, and pressed enter, that
you would get a "fresh copy" of the page with all fields cleared (reset).  This
sounds like yet another way to reset the fields.

IMO, this bug is in great shape, and no further work should take place for Nav 6
at this point.

Based on comments from PDT, futuring it.
Target Milestone: M18 → Future
As of 2000101021, form elements which have no default values are left as is, but
elements which have default values are reset to their default values.
Regardless of what the correct way to handle this situation is, it should not
matter whether the original page had a default value for an element or not.

For example, if you go to the Bugzilla helper at:

	 http://www.mozilla.org/quality/help/bugzilla-helper.html

and fill out the form, then hit reload, most of your entries will be preserved,
but "Steps to Reproduce" will be reset to "1.2.3."

BTW, just to butt in on the previous discussion, on what to do if a user has
modified fields in a form and hits Reload, maybe the best thing to do is just
pop up a dialog and ask what they want.

Since they make expect the form to be saved because of IE's behavior, and since
CTRL-R is relatively easy to hit (especially if you use CTRL-E for end-of-line),
it's not a good idea to destroy their data if that's not what they want.  Since
it's not obvious or straightforward how to clear the data if there isn't a reset
button on the form, it's not a good idea to make this impossible, either.

If we just check if any fields have been changed from default, and if so,
display a dialog asking whether to reset the form (defaulting to No), then the
user can pick what they want.  If this is irritating to some folks, it could
probably be saved in prefs.js if they wanted it to be (ie, a little checkbox
that says "Always do this when reloading a modified form").

Just my 2 cents.  :)

for the record, on 4.7x on Macintosh if I click the reload button (no modifiers), 
I see my form fields getting cleared.
Keywords: nsbeta3 → relnoteRTM
OS: Windows NT → All
Hardware: PC → All
Whiteboard: [nsbeta3-]
relnote3 was nominated because the behaviour changed from PR2 to PR3. Is this a 
useful thing to relnote for RTM?

The blurb:
It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note for Netscape 6 RTM. If anyone feels it does, can they please 
draft one and then nominate with the relnote-user or relnote-devel strings in 
the Status Whiteboard.

Thanks :-)

Gerv

Relnote-user:

Unlike previous versions of Netscape Navigator, if you reload a page containing a 
form, information you entered in the form will not be cleared. To return the form 
to its original state:
* if the Navigation Toolbar is not visible, display it by choosing View >
  Toolbars > Navigation Toolbar;
* click in the location field, and press Enter.

[The following is necessary if there is no way to give the location field focus 
via the keyboard (in an existing window) by RTM.]

If a disability prevents you either from using the toolbar or using the keyboard, 
so that you cannot carry out the above steps, use these steps instead:
* add a bookmark for the current page (Bookmarks > Add This Page);
* open the Bookmarks window (Bookmarks > Manage Bookmarks);
* visit the bookmark (by double-clicking on it, or pressing Enter);
* once the page has loaded, return to the Bookmarks window and delete the
  bookmark.
Whiteboard: relnote-user
Sorry,
`either from using the toolbar or using the keyboard' -->
`either from using the toolbar or from using the keyboard'.

> visit the bookmark (by double-clicking on it, or pressing Enter);

No, this doesn't work either.  Great accessibility, eh?

Can't they just use Open Web Location?

Anyways, nominating for 1.0.  The only two workarounds for this problem, as 
presented in this bug, are shift+reload and pressing enter in the URL bar again 
after the page has load.  Aside from the fact that these are both very obscure 
methods that probably aren't documented anywhere, both of these require you to 
have the Navigation toolbar open, which is, of course, not an acceptable 
solution.
Keywords: relnote3 → mozilla1.0
This seems to be working correctly now: reloading is resetting forms, but 
navigating (back/forward) isn't.
... and "apply theme" isn't resetting forms, which is also good.
nav triage team: as per comments, this is now fixed! please verify.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
*** Bug 83445 has been marked as a duplicate of this bug. ***
Reopening because the reported behaviour is still here, but in bug 83445 it is 
suggested that this bug should become a "feature" and documented. Mark this 
wontfix if you agree.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Keywords: mozilla0.9.2
This can cause dataloss: if I make bug A depend on bug B and then reload bug B,
I will see a link to bug A but the bug number for bug A won't be in the
depends-on text box.  If I then make changes to bug B and submit them, the
dependency will be removed.
Keywords: dataloss
*** Bug 89092 has been marked as a duplicate of this bug. ***
I would like to chime in on this debate.  Conceptually, "Reload" means to fetch
the page again, be it from cache or web.  The page you're fetching already *has*
values for the form elements; the defaults.  It makes little sense to re-fetch a
web page and end up with a version of that page that DOES NOT reflect the source
of that page.

However, if the loss of data argument simply cannot be dropped, then I can live
with a dialog asking for how to handle a reload in the case of altered form
fields (complete with "always handle this way" option and the ability to change
this in the main preferences dialog somewhere)
I'd found form data isn't cleared after submitting.

http://www.mozilla.gr.jp/~kazhik/testcase/1175.cgi

(1175.cgi)
#!/usr/bin/perl
use CGI;
my $q = new CGI;
my $url = $q->url;

if ($q->param('submit')) {
  print "Location:$url\n\n";
  exit;
}

print <<EOT;
Content-Type: text/html

<html>
<head>
<title>TEST</title>
</head>
<body>
<form action="$url" method="get">
<input type="text" size="20"><br>
<textarea rows=2 cols=20></textarea><br>
<input type="submit" value="SUBMIT" name="submit">
</form>
</body>
</html>
EOT


Is this the same problem?
*** Bug 96167 has been marked as a duplicate of this bug. ***
*** Bug 96114 has been marked as a duplicate of this bug. ***
Hazuhiko, do you still see this bug when you submit on your testcase? I don't
see it. I had noticed recently that checkboxes weren't resetting between submits
on certain eBay.com pages. I no longer see that problem, either.
*** Bug 100126 has been marked as a duplicate of this bug. ***
*** Bug 60269 has been marked as a duplicate of this bug. ***
*** Bug 100126 has been marked as a duplicate of this bug. ***
What is even worse than not clearing the textfields is that - at least with
textarea fields - a reload doesn't reflect changes in the html code. 

i wrote a little script which sets always the current time as the value of a
textarea at 
http://www.antifa-aktion.de/mozillabug.php

try to reload a few times and compare the source to the output.
my opinion:
    If I hit reload, I want a brand new page.
    What other conceivable reason would I have for that action?
    Why would I want my old form field values filled in?
    If I wanted them filled in, why would I hit reload?

I ran into this bug while trying to write a test case for another
bug. http://www.wickline.org/mozilla/2001120200/

I expected that I could re-set the test case by hitting reload.
Nope.

Why not save shift-reload for the special behavior of saving
the form input values? It seems to me that wanting to save
the values is the special form of reload.

-matt

I want to add my comments since there seems to be some people who actually think
the current Mozilla behavior in this regard is sane. It is NOT.
I honestly have never ever seen IE or Netscape keeps form field values on
refresh, and I have been using the web since it's inception. Perhaps  my
settings have always been set the same for all these years and I haven't seen it...

However the current implementation does break dynamically created content. When
a page is refreshed (ctrl-r / cache set to Every time...) the form fields stay
the same, and yet all dynamic content (document.writes and so on) other than
form fields is reset. This is inconsistent, and breaks dynamically generated
content that is driven by the data in the form fields. If a test case is needed
I'll be glad to provide one.

The Mozilla fix for this "feature" is to run a script onload that resets all
form fields. This brings me back to all of the little quirks in NS4 that
developers have grown to despise over the years, and have driven the NS userbase
almost to non-existance. 

The best way to implement this feature is to give the choice to the developer to
turn it off or on with a parameter in the input tag. If you leave it on by
default, it will still break current implementations, but it's better than
throwing another Netscape quirk on us developers. 

Someone above said this isn't about developers. Well it isn't about users
either. It's about both. Without developer support though, Mozilla/NS has no
chance of regaining it's former status as the best browser around. Of course
this should be obvious, but sometimes looking at comments on these bugs I wonder.
I firmly (maybe even violently) agree that reload/refresh should
reload the original web page as sent by the server and *not* modify
that. If the input says value="" then I expect an empty string to
be the value when I hit reload. If the input says value="your name here"
then I expect that value when I hit reload.

Some folks want to get all paternal and try to protect users from
using the reload/refresh button to reload/refresh the page when
the user doesn't really *want* to reload/refresh the page.

The solution is to educate the users (dammit!).

May I suggest...

    user hits 'reload'
    mozilla checks to see if warn-on-reload is enabled
      if enabled mozilla checks to see if page contains form(s)
      (maybe just forms with non-hidden form widgets?)
        if form(s) found
          mozilla warns:
              "reload will clear all form values"
              [ ] check here to never show this warning again
                   (_reload_page_anyways_)  (_cancel_reload_)
        else forms not found
          mozilla just reloads
      else warn-on-reload has been disabled
        mozilla just reloads
    now user sees a reloaded page
    forms' values are what they want to see

this gives a one-time annoyance to those of us who know what
a reload button is for. It also educates users who don't know
what a reload button is for.

Please don't cripple the browser to serve the ignorant.

-matt

*** Bug 116677 has been marked as a duplicate of this bug. ***
Since there has been no comment from Mozilla, does status whiteboard mean that
this is not going to be fixed for 1.0 and the next major NS release that
presumingly will be based on it?

I just need to know because I need to fix all of my sites that change the DOM
based on form values. Calling form.reset() is also not a valid workaround at all
as someone mentioned, when some of the form fields have default values. The ONLY
workaround to this feature is to manually reset the fields onload that need to
be blank. Since I have some forms with 30+ fields I have my work cut out for me,
or I decide not to support Mozilla in my apps. 

Mozilla please mark this wontfix or actually fix it please asap. Don't leave
this floating as reopened as I for one have a lot of work to do if this behavior
is final.

One comment.  Lots of sites seem to feel that programmatically reloading the 
page (calling location.reload()) is a clever thing to do in response to, say, a 
resize event.  This is a workaround for a Netscape4 bug with style sheets, but 
the sites do it for both Netscape and Mozilla.  The obvious effect is that on 
such sites opening the sidebar will reload the page and (if this bug is fixed) 
clear all the form data.  I'm not sure there is a good solution to this 
(crippling location.reload() is no good) and I'm not sure we even want to keep 
this in mind when fixing this bug (affected sites should probably be 
evangelized).  But I've often run into this problem when using NS4 and I like 
not having to deal with it in Mozilla...
I agree with the argument that clicking "Refresh" implies that a fresh, 
unedited page will load.  And I also agree with the argument that some 
instances of Refreshing, like a window-resize initiating a location.reload() 
command, should not wipe out the edited field values.

So, why not add intelligence to the Refresh button, so that clicking it *twice* 
initiates a fresh copy?  After all, if a user clicks it once and doesn't get 
the desired result, they'll probably try clicking it again.  Also, isn't there 
an HTTP REFRESH command (or something) that can check for updated HTML, so that 
the form will reload fresh if it's been modified?

(sorry for the spam)

And another thing:  what happens to the field values if you've submitted a 
form, realize you need to fix something, and press the BACK button?  Does 
Mozilla maintain the field values (as desired)?  This, to me, is the likely 
source of dataloss.

P.S. My interest in this stems from bug 55583 re cached sources.
> press the BACK button?  Does Mozilla maintain the field values

Yes, if the page was kept it the cache.  If we rehit the server for the page, we 
don't keep the values (they too are stored in the cache).
Hello,
[Tony Tovar on "refresh"] I disagree. So far I think that "refresh" (somehow
not available in Mozilla 2001112012 but in Netscape4) would redraw the page
from the browser cache if, for some reason, the display got mangled (ie,
window-manager bug). "Reload", however, should reload the page from the
server and make _no_ modifications. Boris Zbarsky writes that many sites
call "location.reload()" on resize for both Netscape and Mozilla, but this
is a bug in their JavaScript code anyway (imho). The "right way" to keep
browser differences in check is not to dissect the version string as the
main source of decision, but to test for objects pertaining to only the
specific browser defects one wants to know about, if at all possible.
So one would arrive to classify Mozilla as DOM compliant while Netscape4
would not be classified as DOM compliant, thus making a difference between
the two browsers the version string may not show (for some simple-minded
browser-detection schemes). Therefore he right thing to do is to evangelize
site programmers and in the meantime have Mozilla reload the page from the
server, imho.

OTOH, stepping back and forth along the history should retain form values
if possible (ie, if one steps back a few pages and then presses submit on
that page, the former "forward" track of history is lost).
obviously, mozilla should do the Right Thing.

In this case, I would argue that the Right Thing is for mozilla to support
recomended practices rather than to encourage antiquated hacks evolved in
response to buggy browser behavior.

buggy browser behavior = NN4 css bug with page resize
        antiquted hack = page author abuses location.reload()

Wrong Thing = perpetuate this page author behavior
              by adding another layer of hackery
              (and introducing additional problems as
              evidenced by the discussion and votes)

Right Thing = let page author clear form data
              let users get annoyed at page's behavior
              let page author learn the appropriate behavior

MHO,
-matt
mozilla folks, should the reload menu idea discussed below be a
new RFE, or does it fit well within this bug?

...


toni, re: your email, my comments were not directed specifically
at your comment #65, but rather generally at those comments above
which argue that this bug should be wontfix'ed.

regarding your distinction between reload and refresh, I don't
think that there would be any general consensus as to which word
meant what, and having both functions available would probably
lead to more confusion that anything else.

*if* there is to be more than one reload/refresh, then I would
think a better UI might be to just use one of those two vocab
words, and use one button, but have that button provide a menu
(like the history menu dropping off the back button) of the
possible ways of reloading...

    reload page from browser cache
    reload page from browser cache & restore form data
    reload page from server (re-submits POSTed form data)
    reload page from server (re-submits POSTed form data) & retsore form data

The parenthetical bit about re-submiting POSTed form data would
only show when appropriate. The ordering of items is such that
the "least expensive" items are first, but maybe some UI folks
would have a better way of doing it.

In any event, the above are four different types of reload, and
my opinion would be that if you pick four different words for
the above actions (reload, refresh, rerender, redraw) then you
will probably be hard-pressed to find a "best" mapping from the
one list to the other. For less user confusion, perhaps the four
actions could be made available in an explicit list.

My preference would be that the default button click would do a
    reload page from server
without any form data restoration... just restore the default
values as specified in the page source.

-matt

(toni: MHO meant IMHO w/o the 'I')
Please report any new feature requests as separate RFE bugs.  
comment #67 has been made into bug 118625 for those who are interested

-matt

This is a bug I've "looked at from both sides now"... There are times when I've
been glad that Mozilla preserves my form input despite reloads being forced by
various sorts of annoying page coding, or when I have to reload a page because
the server glitched somewhere in the course of loading it, but I've already
started filling out a form on it... and I'm very worried that a "fix" of this
"bug"/"feature" will result in more instances where just using the back and
forward button, resizing a page, etc., will blank out form inputs.

On the other hand, I've also sometimes been frustrated when a dynamically
generated page that includes textareas and form fields refuses to reload
completely from the server in any easy way when I want it to.  This includes
pages I'm developing, where I'm trying to test changes including changes to
input defaults, and have trouble seeing my changes because my previous inputs
stick around on reload.

Thus, I'm two-faced on this bug and not sure which way I'd like Mozilla to go.
*** Bug 119262 has been marked as a duplicate of this bug. ***
*** Bug 126103 has been marked as a duplicate of this bug. ***
The "some pages coded for Netscape 4 call location.reload in onresize" argument
is irrelevant, because <body onresize="window.location.reload()"> clears form
values in both Netscape 4 and Internet Explorer 6.  If a page with a form larger
than a search box used that code, they would have already heard from their
Netscape 4 visitors.
I've always used history.go(0) for the onresize event in Netscape 4 to get the 
page to refresh. Form field values are maintained. location.reload() wipes out 
the form field values. 

This was identified as a change in version 4.0.12 of Hiermenus, but has been 
fairly well known for quite a while.
http://www.webreference.com/dhtml/column55/3.html

Regardless of the JavaScript behavior, when the user clicks the reload button, 
the page should be reloaded and no form values should be stored.

*** Bug 127943 has been marked as a duplicate of this bug. ***
*** Bug 128303 has been marked as a duplicate of this bug. ***
*** Bug 123659 has been marked as a duplicate of this bug. ***
Blocks: 134987
Got a solution! 
Add autocomplete="off" in the input tag, and voila! Refreshing the page will
reset the value.
That's mean autocomplete attribute should be "off" intead of "on" by default?
The fact that the autocomplete attr (which should control whether the form 
manager prefills those slots in the form) affects reload behavior sounds like a 
bug to me.
I don't think it is a bug. Although it might have been a side effect, it really
 is an almost optimal fix for this bug. I do think turning autocomplete off by
default would be best, but I'm happy with this solution. 
In my little rant on this bug a while back, I said I felt the best way to
implement the reload protection, would be with an attribute in the input
tag...and here it is.

When you think about it though, like you said, the whole reason for the
autocomplete attribute is to give the developer the ability to turn autocomplete
off. Mozilla recognizes that developers do need to have complete control over a
form at certain times, and have provided a way to do it. The same reasoning
follows here. So don't go and spoil my party, ok? ;) I hope we will be hearing
from Mozilla on this soon though.


Just some note for anyone interested, the autocomplete attribute property is not
writeable using the setAttribute() or removeAttribute(). Also when setting
autocomplete on, and typing in some text, then editing the document to turn
autocomplete off, the text disappears. Interestingly enough, if you then turn it
back on and reload, the text appears again.  I don't think that it matters, but
for curiosities sake...
hm, I think we should not remember element's value when reload. Because it 
makes confusing. But we should remember it when back or go to any history page.
Just like NS4.x and IE's behavior.

Autocomplete off by default sounds good to me, or set in preferences. Maybe
there are some other settings (I could think of, open Dom Inspector, open JS
window), that would compile a "Developer Mode" vs. "User Mode", to make it into
something more transparent for an end-user.
The purpose of the autocomplete attribute is NOT to enable/disable
reload-preservation of form fields. It is to enable/disable autocomplete. If you
change the default to autocomplete=off then autocompletion of form fields will
be broken for all sites except the rare few that have been specificly designed
with Mozilla in mind.

At present, the workaround for this bug is to always press Shift+reload instead
of just pressing reload by itself. I think the owners of this bug simply expect
all Mozilla users to get used to doing this.
This bug is not only about the user interface, that's a minor issue. There is a 
very real dataloss problem here. Please read the previous comments.

There is however a problem with the UI also. Most forms these days do not have 
a reset button since users have gotten used to just refreshing the page and 
it's too easy to hit a reset button accidentally. You cannot expect every 
single user to know to hit shift-reload or ctrl-shift-r to refresh a form. 
Windows users are too used to using their mouse only, and have come to expect 
it. How many Windows users do you know that actually use ctrl-c and ctrl-v? A 
mouse/keyboard combo is even more unintuitive for a newbie imho.


I'm not looking at this from an 'consumer/visitor' point of view, but from a
webdeveloper point of view.
I use keyboard shortcuts a lot, but ctrl-shift-r vs. ctrl-r makes quite a
difference - plus - you don't _realize_ this is an issue!

It took me two hours to figure out, it wasn't my code, but Mozilla that
displayed the wrong results - can you imagine how **** you feel at such a
moment? Would you take up developing with Mozilla again?

And who are the primary users of Mozilla? Indeed - webdevelopers, because of the
standards compliance. We are the ones, that have to educate the end-users, show
them, that other products are inferior - but if we don't like working with it,
what will happen, then? I mean - even the view-source suffers caching problems -
luckily I rememberd this bug, and opened the page in Opera, to see if my hunch
was right - and there you have it -> I have another product open, to check if
what Mozilla is showing me is correct!

Please don't take this the wrong way - it's meant as a constructive critism,
from a person who would like to see the browser succeed, but fears these
cacheing shortcuts may be it's downfall.
Can cause users to submit incorrect form data: Severity --> critical.
Severity: major → critical
*** Bug 142110 has been marked as a duplicate of this bug. ***
*** Bug 143081 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
*** Bug 149905 has been marked as a duplicate of this bug. ***
*** Bug 150414 has been marked as a duplicate of this bug. ***
*** Bug 150582 has been marked as a duplicate of this bug. ***
 I have raised the issue here regarding the (non) resetting of a combo box on refreshing the page (I believe it should reset because the form specifies a selected attribute on one of the options and so this should be the default). It will reset using shift+refresh or by putting the cursor in the navigation/URL field and hitting return. Konqueror and IE 6 both reset back to the default form values on refresh. Also, the behavior that I am looking for - which is to set a couple of related combo boxes to default values is broken by this bug (and thus so is my feature :-( ).   Whats worse is that intuitively, I believe that this should somehow be related to the ability to remember values entered into a form - but it isn't since altering this ability through preferences doesn't make any difference.   my 2 cents. 
Maybe set the defaults to match the others browsers defaults mode. I matched the
problem when I used multiple inter dependent combos ( the first reload with the
2nd modified, the 2nd with the 3rd...  ), and, huh, useless by default in
mozilla :(, and we lost the 'ergonomy' of this feature if we have to ask the
user to press shift refresh (note ctrl-shift-r does not work ;) ).
Regarding dataloss: this is not any worse dataloss than back/forward, and we
can't get rid of that because users *want* it.  Not only that, you guys can fix
your pages!  You can:

- Put Cache-Control: no-store in the header to keep all save/restore from
happening on the page.
- Put autocomplete=off in the individual form controls to turn it off in the
critical ones.

The current behavior is good for *users*, even though it's not good for the 90%
of people here who are serious web developers.  What normal user *thinks* about
abstractions of fresh pages and stuff?  They are thinking of their Search field
as a search field, not as an <input> tag in a webpage.  They don't know that
when they reload the page it's a completely different form and a completely
different tag.  They know they typed something in their field and when they
reload if the data is still there, they will be completely accepting of it, and
even thankful in the case of a long missive in a bulletin board.

The thing is, with current behavior, the user has the *option* of deleting the
data he entered when he hits Reload.  If we fix this bug, the user cannot go
back to the text he entered with any amount of effort.

IMO, WONTFIX is the right option here.
Severity: critical → normal
I'd disagree. As far as I'm concerned, as a user and a web developer, when I hit
'Reload', I'm asking the server to send again what the page looks like in it's
original, unchanged state, and the server does that. The data which is cached in
the form controls is not coming from the server - it's coming from the client.
It's not up to the client to decide what should/should not be cached. 'Reload'
to me implies that you return to precisely the state that the page would be in
if you were to visit it for the first time.

Bug 134987 discusses the implications of this and the option to warn users that
reloading will clear the form, which I think is the better option.

Whilst the suggested workarounds will indeed work, I don't think it addresses
the basic issue that the client is basically deciding what to display,
regardless of what the remote server is telling it to display - this does not
seem right to me.
Why would a user hit reload in the middle of composing a big webboard post? 
Because they want to reset the form to the way it was, i.e. they want the dataloss.
In Bugzilla I often meet 'mid-air collision'. So I go back (using Back button)
and reload whole bug page to get new comments and changes. I'm VERY HAPPY, that
my form data doesn't disappear while this action. Agree with WONTFIX.

Form reset should be in context menu for forms. 
I comment on this bug way to much, gotta keep the torch alive though. Anyway
here goes..

Let me just say that, I'm not as concerned about this bug as I used to be
because there is finally a way to work around it (undocumented anywhere by
Mozilla or Netscape until you just said it to my knowledge, this was relnoted
but didn't make it into the release notes..), but there are many developers who
will not be aware of the workaround. Take the Mozillazine forums for instance.
The title field keeps old topics that you typed in even though all you wanted
Mozilla to remember was the username and password field. I think that is
annoying, and definitely not good for your average user to have to keep having
to delete that field for every post.

So what does a user think when he sees the topic field always staying the same?
I'll bet that they think that something is buggy with the site or the browser.
Definitely not a good thing, and yes, I know how to use the form manager, but
will most users?
 
Now, Mozillazine is run by some of the people most intimately familiar to
Mozilla and they either didn't have the time, or maybe don't even know about the
simple autocomplete=off fix. So what makes anyone think that the other thousands
of web developers are going to know it? Most certainly will not know how to turn
off caching. So both workarounds are pretty much meaningless, because they wont
be used, and autocomplete=off has a slightly different behavior in IE as well.

The real issue in of bug now though (Mozilla's behavior here has changed
multiple times since this bug was filed), which is that Mozilla _does_ reset
hidden form fields when going backwards, forwards, and on refresh. However it
leaves visible fields intact, which may have been used to calulate the value of
the hidden field via javascript. Then when the user submits the page to the cgi
script, data corruption occurs. This obviously is not the same type of situation
that occurs when going backward and forward at all (IE6 will keep hidden and
visible...sometimes). The same problem can occur on any page where javascript
sets form fields, which is very common.

Part of the problem is something which I don't totally understand. IE will keep
both the values, sometimes, in some testing it seemed that whenever I changed
the htm file to a cfm (cgi app server) file IE would stop caching, but Mozilla
continued it's autocomplete behavior. Looking at the http headers, and I'm
totally speculating that IE does not send the cache-control header when it sees
a file it suspects may not be static html, but Mozilla continutes to do so. You
can see this here http://24.73.19.182/automoz.cfm 
I'm not sure of the underlying mechanism behind IE doing this, but here is one
place where IE does get it right and Mozilla is not imho.
 
If Mozilla is going to keep the values, then it should keep them all, but I as a
developer would prefer that the feature be turned off by default, for the
reasons mentioned in the Mozillazine example. It solves both problems easily.

One thing I can guarantee is that every single web developer in the world that
trys to develop a form in Mozilla with any kind of javascript interaction is
going to run into this problem, and they are going to be pretty upset after
hours of debugging (and refreshing...) to learn that it was Mozilla's fault, I
know I was. 


Heh...speaking of mid-air collisions, three people made comments while I was
typing this beast of a comment. I clicked back, and my stuff was still there.
Awesome! The other still issues need to be solved though, and they can be, as IE
shows.
Shoot, I forgot. In order to see the difference in what IE sends versus Mozilla,
on the link in my post, refresh the page once in each browser.
In some cases, because form elements are not reset, it is actually *impossible*
for the user to return the elements to their original state. In the case of
radio buttons, the original state may come up with no radio buttons in a group
checked. However, once a radio button is checked it is impossible to return the
group to a state where all buttons are unchecked. One will always remain checked.

In other cases, may not be able to return the page to its original state simply
because he does not remember which values he has changed.

I think that these are two arguments in favor of resetting.
> Why would a user hit reload in the middle of composing a big webboard post? 

Why would a webpage call location.reload() in the middle of the user composing 
a big post?  A number of pages do just that....

> Mozilla _does_ reset hidden form fields

Bug 149962 (and fixed).

Pages had better not be depending on radios not being preselected by the UA; 
see http://www.w3.org/TR/html401/interact/forms.html#radio
Comment 95:
> - Put Cache-Control: no-store in the header to keep all save/restore from
> happening on the page.

And completely unnecessarily prevent caching? I think not.

> - Put autocomplete=off in the individual form controls to turn it off in the
> critical ones.

autocomplete? Huh? What? Who? Where? That attribute doesn't exist:
http://www.w3.org/TR/html401/interact/forms.html

Comment 98:
> In Bugzilla I often meet 'mid-air collision'. So I go back (using Back button)
> and reload whole bug page to get new comments and changes. I'm VERY HAPPY, that
> my form data doesn't disappear while this action.

Think about it! You type a comment, you get a mid-air (perhaps because someone
has changed the summary, url, keywords and status whiteboard fields), you go
back, hit reload, the form elements does *not* reset, you hit submit, *thus
overwriting the changes to the summary, url, keywords and status whiteboard fields*!


Scenario:
A page on some internal network contains a big <textarea> with some notes in it.
When someone visits the page, the server sets a cookie containing the time and
date of when he/she loaded the page. Anyone can change the contents of the
textarea, but upon submitting the form, the server checks the cookie to see when
you loaded the page, and checks whether anyone has made any changes to the field
in the meantime (this is done to prevent users from accidently overwriting each
other's changes).

I visit the page and look at the textarea; it contains three lines. I add a
fourth line. Before submitting, I reload the page to see if the webmaster has
activated that fancy new design he has been talking about. He hasn't. I hit submit.

In the meantime, someone has composed the sequel to War and Peace in the
<textarea> and submitted it. Which is no problem, as the server will check my
timestamp cookie when I submit my four lines to make sure that no changes have
been made in the meantime, right? Now, when I reloaded the page, the cookie
naturally got updated with a fresh timestamp, but that is just fine since
reloading will also cause any new changes to appear in the textare, right?

...right?

No. Because of this bug, the <textarea> was *not* updated with the new contents.

Congratulations, you just destroyed the sequel to War and Peace. If that is not
critical dataloss, I don't know what is.

[Adding nsenterprise keyword and adding to tracker of bugs which make Mozilla
advocacy harder, as this is currently the only bug preventing me from
recommending Mozilla over IE for corporate use.]
Blocks: advocacybugs
Severity: normal → critical
Keywords: nsenterprise
Wow.  This is quite the talkative bug.

To repeat my comments earlier re: "easy work-arounds"...

Browsers since the dawn of time have reset forms on a reload.  Changing that
behavior now is VERY arrogant.  Saying "We're changing the default behavior, but
you can go back to the old behavior by changing YOUR stuff" sounds *exactly*
like what Microsoft was trying to do with Smart Tags back when IE6 and WinXP
were just starting to generate hype.  And it also throws us back into the realm
of needing to build code to specifically handle each browsers' special quirks. 
And since most users (and developes) use IE now, how often will the special
quirks of Mozilla really be taken into account?

The ability to keep form fields in a refresh is actually nice.  But it shouldn't
be the *default*.  Having the option in a context menu or dropdown-menu for the
reload button would work, as would a pop-up asking which behavior the user wants
(along with a "always use this choice" checkbox).

>Why would a webpage call location.reload() in the middle of the user
>composing a big post?  A number of pages do just that....

I don't know why they'd do that, but the point is that the DEVELOPER made that
decision, so they have to live with it.  Developers shouldn't have to fight the
browser, they have enough problems getting *themsleves* to work correctly.  When
the browser starts deciding what a page's content should be *without* the user
telling it to do so, you've got a problem.

At the very least, when you reload a page, form elements with a value=""
attribute should be changed to reflect that value (same with textarea).  Why
shouldn't it?  I mean, if I change my html source from <body bgcolor="blue"> to
<body bgcolor="red"> and reload, the page changes, right?  So how come if I
change <input value="blue"> to <input value="red"> it doesn't?

And I admit that my arguments above are entirely developer-centric instead of
user-centric.  However if developers have a hard time making things, the things
they make will be of less use to the actual users.

Another possible solution:  Come up with some way to store "pre-reload" form
values, and provide a menu option to re-fill those in, for canses of accidental
reloads.  Yes, this makes the process non-transparent, but it doesn't break any
existing behavior, and puts a special-case solution in a special-case
location... under a menu of some kind.  (Yes, most users won't even think to
look for it... uh... okay, I'm stopping now before I completely lose focus.)
The subject of this bug is the behavior of Reload and Force Reload. Reload is
called by the Reload button in the Navigation Toolbar, or from Ctrl+R, or
Whitespace Context Menu | Reload. Force Reload is called by Shift+Click Reload
or Ctrl+Shift+R. 

Currently, Reload attempts to get a new page, and then restores user entered
data into form elements. Force Reload forces a proxy to reload the page, and
does not restore user entered data into form elements.

The question posed by this bug is: should Reload no longer restore user entered
data into form elements, but instead mimic the behavior of Force Reload as it
concerns form elements? Form elements include drop down boxes, radio buttons,
checkboxes, and textareas. 

To answer the question we shouldn't rely on what a new Mozilla user would
expect. The behavior of other browsers will create expectations in the minds of
new users. If the behavior of other browsers is suboptimal, however, Mozilla
should take a better approach.

This is a topic where there is no applicable standard. The W3C has not addressed
autocomplete functionality in web browsers. Thus, they do not have a relevant tag. 

Autocomplete=off is a good workaround. It is a proprietary tag supported by both
IE and Mozilla in an attempt to fix a problem that the standards don't address.

As comment 99 and comment 103 said, Mozilla does not work the same way as IE,
and because of that certain web site designs create the potential for data loss.
The solution, though, is to add autocomplete=off to the form tag. Although
autocomplete=off doesn't work in the textarea tag, it does work in the form tag,
for all the form elements including textarea. In Mozilla, autocomplete=off works
fine when put in the form tag.

On a related note, the W3C is introducing XForms. Bug 97806 would implement
XForms in Mozilla. Maybe XForms will have a standard for handling
autocomplete-like functionality. There is a "refresh" action in the draft
proposal. If it happens, it would be good, but it doesn't help us right now.

That leaves the other concern raised: that not fixing this bug would make it too
hard to create web sites. 

We could avoid this issue by making the user decide what to do by showing him a
dialog box. We could add a configurable preference for what Reload should do
with forms. These are bad options, though, because Mozilla already has too many
dialog boxes and a bad case of preferencitis. 

Mozilla should do the right thing. To determine what that is, we need to
consider the goals. They are: making it convenient for web designers to create
web sites; protecting users from unexpected data loss; and allowing users to
easily reset forms to their original values.

When I first started using Mozilla, one of the features that won me over was how
it saved the data I typed in textareas. If you navigate back from a textarea,
and then return, you'll probably lose the data in IE, but definitely not in
Mozilla. For example, in Mozilla go to http://slashdot.org/ , select a story,
click on reply, and type something in the textarea. Then, hit the back button.
You can go back several pages. Now use the forward button to return to the
Slashdot form. Your data is still there. This is nice, and it doesn't happen in
IE. If you type a novel in IE, then hit back, then hit forward, you lose the
novel. The page is reloaded. IE wipes the textarea. The same problem occurs if
you accidentally click on any link while typing in the textarea, then try to go
back. This problem isn't unique with Slashdot forms. Other web sites do similar
things. If this bug is fixed, Mozilla users would most likely lose this valuable
protection for their data.

Comment 96 said that if we wontfix this bug, "The client is basically deciding
what to display," but that isn't true. Instead, the client is deciding whether
to keep user entered data. The web is not a broadcast medium; it's interactive.

Adding autocomplete=off to form tags or input tags is not hard. Web designers
can do that easily. It's much easier for web designers to add that than for
users to get back their lost data.

Some people point to Mozillazine as an example of how hard autocomplete=off is
to figure out. First, Mozillazine is awesome. Unfortunately, it has experienced
a number of bugs. It's not the best designed web site in the world. I still love
Mozillazine. A lot. The bottom line is that the example of Mozillazine is
inapplicable here.

In the past, I was briefly annoyed at Mozilla's refusal to reset forms. If you
make changes to a Bugzilla form, forget what the changes are, but then need to
change some of the elements back to the defaults before submitting, a Reload
will not reset any of the form elements. This was frustrating until I learned
about Force Reload. We should improve the discoverability of Force Reload by
relnoting it, putting it in the Help files, maybe putting it (along with Reload)
under the Go menu, and maybe renaming it to Force Reload/Reset. Discoverability
is not a serious problem, however, as most users rarely deal with forms.
Enterprise users who need to Force Reload can learn how easily.

This bug carries the access keyword. We could better address this issue by
putting Force Reload under the Go menu.

Mozilla should err on the side of protecting user entered data. Thus, we should
keep the current behavior and mark this bug wontfix.
You can't compare Back/Forward to hitting reload. From a user expectation point
of view they're not the same thing. If I hit back/forward, I *expect* the form
elements to not be reset, but when I click "reload", I expect the page to
*reload in it's entirety*, including form elements.

> Autocomplete=off is a good workaround. It is a proprietary tag

It is not a good workaround for the very reason that it *is* a proprietary tag.
We should be moving towards *standards* to make designing cross browser
compatible sites easier, not harder.
Is the patch in the 2002061308 build?

I can repro the first testcase. Only after 2 or 3 reloads the typed text
dissapears...
> The same problem occurs if
> you accidentally click on any link while typing in the textarea, then try to go
> back. This problem isn't unique with Slashdot forms. Other web sites do similar
> things. If this bug is fixed, Mozilla users would most likely lose this valuable
> protection for their data.

Why? What happens on back/forward is unrelated to this bug. We're talking about
*reload* behavior here. There's no reason why we can't reset the form elements
on reload but still remember them on back and forward.
I'm with you 100%:  should not -- or else where would we use form value
restoration? -- be included in this bug.  But the summary does not make it clear
enough that this bug refers to manual refresh/reload only, which explains the
confusion above.  I suggest adding the words "manually" and "refreshing" to the
summary:  "Form elements don't reset upon manually reloading/refreshing page". 
I think that would be a win-win situation, because 1) no words are removed from
the summary, so people could still find it the way they can now; 2) more
variations on keywords in the summary makes it easier to find; and 3) it would
be clear that it refers to manual reloads only (not back/forward).
Would fixing this bug have any effect on pages that are set to automatically
reload? 

On an unrelated note, if we fix this bug, upon manual reload we should put all
the changes to the form state into Undo/Redo. That way a user can get back their
data even if the user accidentally hits the reload button, or manually reloads
because part of the page or an image didn't download, or wants to see an updated
copy of a dynamically generated page, but does not want to lose the data that
they just typed.
Keywords: mozilla1.0 → mozilla1.1
Summary: Form elements don't reset upon reloading page → Form elements don't reset upon manually reloading page
Andrew, I guess fixing Bug 134987 would solve one of the issues you raise.  As
for the other case (you want an updated copy of dynamic page but want the UA to
remember the values you entered into some forms), here are some concerns:
- what if the page comes back with different forms, different controls or
something?  Should we then just do our best to match up the names we have for
the forms and form elements from the old page?
- What if the same names now correspond to different types of controls?
- And what if the new forms/controls are in a different order and have no
name/id attributes?
(I haven't seen these points raised by anyone else.)  The point is that I don't
think there's any guarantee that refreshing a page would even give you the same
forms/controls to deal with.  It seems to me this is one reason it's bad form to
restore form values on reload in the first place.  I guess what I'm trying to
say is that if you want a new version of a dynamic page that has forms, but want
to keep values you entered then:
1) don't fix this bug (not to appetizing)
2) don't enter stuff in a form and expect it to still be there on reload

Looking at it another way, it is sort of the spec that fails us here, because
there is no way to communicate to the user agent which fields are/aren't subject
to change/removal on reload.  For example, the "Additional Comments" control on
this page is not subject to any updates on reload, and it will always be present
in the page.  If there were a way to communicate that information to the user
agent, through an attribute -- e.g., "static" or something -- then the user
agent would be able to restore the user-entered value for that control on
reload, and wipe the user's changes to other values that didn't specify "static."
But there is no such animal afaik (maybe in XForms does?).  Unfortunately, I
think we just can't have it both ways.  And I just don't think it is proper/good
form to be restoring user-entered form values on an explicit manual page reload.
I don't agree that there should be a confirm dialog box. We have too many dialog
boxes already. Another one in this context would be pointless and annoying.

If the undo data is mismatched badly with the new form controls, just don't
undo. Even if the undo data generates no error, but still goes in the wrong
boxes, at least the user didn't lose significant data. They can, in this
inevitably rare and worst case scenario, save what they typed. 
Comment #111 wrote:
> What if the same names now correspond to different types of controls?


I have had to tell users to use MSIE for *exactly* this reason. I hate doing it,
but it's easier to tell users to use a client that doesn't override the data
sent by the server than to train them to learn about how this bug works and when
they can expect good data to show in the form, and when they can expect bad data
to show. I use mozilla myself, and cringe every time I have to do a shift-reload
because I know that most users will never "shift-reload" in their lifetimes.

It pains me to tell folks who *voluntarily* downloaded mozilla that they need to
give it up for this web application, and that's why I've voted for this bug to
be fixed.

Note that this bug also blocks bug 92997 (makes mozilla advocacy harder). If
mozilla-loving geeks have to push msie on their users, then we have a certain
advocacy problem.

-matt

>Even if the undo data generates no error, but still goes in the wrong
>boxes, at least the user didn't lose significant data. They can, in this
>inevitably rare and worst case scenario, save what they typed. 

But will the average person even notice?  Say there's two textareas on a page,
Info1 and Info2.  Both are filled out, and then the user inexplicably pushes
reload.  The new page as Info2 and Info3.  The old second field is now the new
first field, with a blank second.  Most users' first response would be: Aww, my
second response was lost!  They would then re-ype the second response and hit
Submit.  THIS is also data loss of a sort, because they have submitted
information they did not mean to.

And yes, such a weird form would be bad design.

And as for this question:

>Would fixing this bug have any effect on pages that are set
>to automatically reload?

You mean like with meta tags/HTTP headers and/or Javascript?  Yes, probably. 
But isn't it pretty stupid design to have pages with forms automatically refresh
in the first place?  Developers have had to "deal" with this behavior forever...
it's not like changing to the expected behavior will break existing pages...

Personally, I think the best solution is to have some sort of "redo" effect for
forms, essentially keeping two sets of form data for every page - one that's
currently shown, and another from before the most recent reload.  This becomes
useless if the user performs several reloads in a row, however, and also
requires some sort of GUI.  However, I bet this functionality wouldn't even be
needed by a vast majority of users.
In the example above, Mozilla could save info1 and info2 data into redo or undo
upon a manual reload of the page. Then, if the reloaded page came back without
an info1, but with an info2 and an info3, then hopefully, if the user tries to
"redo," Mozilla would detect that the data it saved for info1 can't be restored
anywhere, would throw an error, and refuse to redo. In this very rare case, the
user would lose data, but at least Mozilla did everything it could to preserve
the user's data.

Good point about automatic refresh. To amplify what you said, the same redo/undo
functionality would be available anyway.
Blocks: 154170
Adding autocomplete=off to a form is not a solution.  That prevents Mozilla from
restoring the contents of the form when the user hits Back or Forward.  I
imagine that a cache-control header does the same thing.
Adding nsdogfood keyword (justification: Due to this bug, I'm unable to use Moz
to debug web applications.)
Keywords: nsdogfood
I was thinking the same thing until someone pointed out shift-reload.

Now I just do that. It's annoying, but it does the job.

-matt

*** Bug 165590 has been marked as a duplicate of this bug. ***
Blocks: 166560
No longer blocks: 166560
*** Bug 177345 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.1 → mozilla1.4
I was going to report this as a bug, but finally found it here. Currently, if
there is the form tag has autocomplete="off", the fields get reset during Back
and Forward navigation. I can't find anybody that thinks this is good... in
fact, it seems to be a very bad thing. 

autocomplete should *only* affect autocompletion of form fields, not the
persistence of state during navigation. At least, that's my opinion :)
Ben Houston, see also the discussion in bug 180117.
*** Bug 185817 has been marked as a duplicate of this bug. ***
*** Bug 193143 has been marked as a duplicate of this bug. ***
*** Bug 198189 has been marked as a duplicate of this bug. ***
*** Bug 200093 has been marked as a duplicate of this bug. ***
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 210095 has been marked as a duplicate of this bug. ***
*** Bug 210440 has been marked as a duplicate of this bug. ***
*** Bug 211859 has been marked as a duplicate of this bug. ***
*** Bug 216181 has been marked as a duplicate of this bug. ***
It's not my habit to pollute a bug comments, but I think this one deserves to be
rediscussed.

The bug has many votes and high number of duplicates:
- this bug is currently the 43th most duplicated Browser bug and the 5th most
duplicated bug with a severity higher or equal to critical.
- the bug as now 22 votes. It's part of the 163 Browser bugs with more than 21
votes. It's also one of the 7th P1 Browser bugs with more than 21 votes, and the
most voted bug with a severity higher or equal to critical. But it's still
targeted to future.

Furthermore there's not been any constructive talk in that bug for more than one
year. That makes it a high candidate for retriaging/refocusing.

I am personally hitting the problem in an about to be currently deployed
application. I admit that shift-reload solves the problem but it's not a
solution for non-knowledgeable users. Furthermore, using Reload only creates an
inconsistent state where some of the fields (like non editable text fields) are
reset correctly), but other text fields keep their overridden values.

This could also create other problems to my point of view.
Let's say a page contains a drop down list with 3 items. None selected
initially. The user selects the third one. The user reloads and the newly
generated page only contains 2 items in the drop down list. What should mozilla
select?
What if after reload there are this time the same number of items but the
meaning of the content has changed. Why should mozilla pre-select an item based
on former form content? I understand the benefits when doing back/next but
that's not an excuse to create such inconsistent behavior. That's confusing and
decisions are not simple to make.

I would really like this issue to be rediscussed.
A suggested fix (from my POV as both a user and a web developer):

- reload *always* resets form information.

- the "back" button triggers a "restore form data?" dialog box,
   IF the previous page has been loaded from the cache.
   AND IF form data on the previous page was modified by the user.

  This lets mozilla keep the desirable feature of preventing back <-> forward
data loss.  It also avoids developer frustration (which I had plenty of when I
realized this was mozilla's default behavior).

  Preventing data loss is admirable, but not at the cost of breaking
functionality as basic as "reload".

(and it is broken.  The number of duplicate bugs should be evidence enough).



> the "back" button triggers a "restore form data?" dialog box,

No.  No dialog box.

Perhaps the right thing to do is to differentiate the "reload" and
"back/forward" cases in session history and not restore form data in the former
case.  If there is agreement from whoever now owns this code (Adam? jst?  Some
UI person?  No idea who it really should be) to that effect, I would be willing
to try and do it.
You're right.  Normally I'm dead against more dialog boxes too.  

I thought this might be an exception because users are accustomed to dialog
boxes on forward and back operations ("This page contains POST data.  Do you
want to re-send it?")

  But simply differentiating the reload behavior from the back/forward behavior
is a good solution.

   A suggestion for managing this as an option:

/-------------------------------------------------
|  Keep modified form data    [] on reload
|                             [] on back/forward
\-------------------------------------------------


> "This page contains POST data.

This should only happen on very rare pages (secure no-store pages) if the cache
settings are reasonable...  Even then, it's arguably a bug.

This is also not the sort of option for which it makes sense to have UI, or even
a hidden pref.  It should be something we just decide on and do one way or another.
Well, I'm really not sure what caching has to do with this, because even pages
with a no-cache directive should *not* reload when you just go Back to them.
As I've said before, going Back should be equivalent to having opened a link in
a new window and then closing that new window.

Similarly, there should never be a prompt about POST data when you just use
Back/Forward.

Of course, this is all my opinion and point of view, but this is how Opera
behaves and I've never seen this as a problem. Quite to the opposite, I've found
it rather pleasant/useful.
I don't think that would work for the issue that got me into this in the first
place.  I had a browser window that refreshed periodically where I could rate
things with a set of radio buttons.  If it was unrated, however, none of them
would be selected - or at least, none of them would if mozilla hadn't helpfully
filled in the last value.

Since the page refreshes every minute, putting a dialog in there isn't going to
help my cause at all.
In Comment #135...

> I thought this might be an exception because users are accustomed to dialog
> boxes on forward and back operations ("This page contains POST data.  Do you
> want to re-send it?")

As a user accustomed to such actions, I'd like to point out that the message
described is an outstanding candidate for a little check box that says "Never,
ever, under any circumstances show me this freaking annoying dialog box again."

ANOTHER freaking annoying dialog box is not required.
> ith a no-cache directive should *not* reload when you just go Back to them

This is the theory, yes.  In practice, online banks block browsers that do this
faster than you can say "please, no", since a session history that behaves like
this makes it possible for someone to come along, hit back, and get info on your
account.  Hence _only_ for https pages, do we not act this way..

In any case, all this is tangential to the bug.  What's really needed here is
module owner feedback on comment 134.
Forget the dialog box suggestion.  That was a bad idea.  Dialog boxes nearly
always cause more problems than they solve.  Mea Culpa, I should have given it
more thought.

Reload leaving boxes filled in is convenient for debugging.  If we do change
Reload to clear everything out, it would be nice if the "reload but leave
formfields alone" behavior were available through JavaScript, so a bookmarklet
for this would be possible.

OK.  After some testing by Lloyd (daltonlp@daltonlp.com) it looks like the
reason people don't see this problem with IE is explained in comment 13.  In brief,

1)  If the reload fetches the HTML from the cache, IE restores the form values
2)  If the reload fetches the HTML from the network, IE does not restore the
    form values.

This leads to totally unpredictable behavior for users, since they can never
tell whether the HTML will come from cache or network, hence whether the form
will be cleared or not.  On the other hand, it leads to totally predictable
behavior for web developers, since they're reloading a page after changing it
server-side and hence it ALWAYS comes from the network.  Further, typical CGI
scripts don't send any Last-Modified headers and hence are reloaded from the
server every time on reload.  Hence the claims that IE does not restore form
values that's made so often in this bug.

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncodecorn/html/corner122099.asp
for some (inadequate, since it does not mention when the form data does not
stick) documentation Microsoft has on this (again, thanks to Lloyd for the link).

None of this indicates what Mozilla should do, of course.  Implementing what IE
does is not acceptable, because of the unpredictability for the user.
Here's a more recent summary of IE's behavior:

The form is repopulated only if the following items are true:
    * The Web page is not an HTTPS (or secure) Web page.
    * The page is cached to disk.
    * The page has not changed since you filled out the form.

from http://support.microsoft.com/default.aspx?scid=kb;en-us;174550

I agree that this creates unpredictability for the user.  I agree that mozilla
should have a better method.

I don't think we're quite there yet :)
Ok, after much more thought:

Form data handling is an area where there's no established spec to follow. 
There are two extremes:

1) Keep all form data on reload/back/forward
  (this is the current default behavior, with shift+reload invoking mode 2).

2) Don't keep any form data on reload/back/forward
  (some security-conscious and developer-oriented folks would like this)

  I'd humbly suggest making form data behavior dependent on a mode switch,
changable during run-time.  Two modes are described above.  More may eventually
be defined, by mozilla developers or the W3C.

  The debate over how to present these modes to the user, and which mode to
choose by default, is separate.  Right now, changing modes requires recompiling,
which makes the whole debate not very efficient.
Please, can somebody plausibly explain to me how back/forward have anything to
do with reloading? Reloading should reset form elements because... well, because
reloading is a sort of reset kind of thing; back/forward, of course, should not,
because it's just going back to where you were. If you wanted to lose your data
in the form after a back/forward, you could still just reload.
> Please, can somebody plausibly explain to me how back/forward have anything to
> do with reloading?

Unfortunately, reload is tied to the history mechanism in NS4 and IE, hence also
in Mozilla.  Which means that it does act much like back/forward and worse yet
pages depend on this behavior... (as in, many pages out there programmatically
call reload() and expect that to NOT wipe out user data...  in NS4 it doesn't
even wipe out the effects of DOM manipulation, which is even more bizarre).
*** Bug 225627 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 219169 has been marked as a duplicate of this bug. ***
The case I care about, which is touched on in comment 55 (and maybe elsewhere;
this bug history is too long to read easily!) is where the page has changed on
the server, and you hit reload, and don't get the new server values.

A pointed example (using Bugzilla!): you load a bug and it has priority P3.  You
leave this window open while someone changes the priority to P1 and adds some
comments.  You want to add another comment and have noticed the added comments
and to avoid the midair collision you hit reload.  Then you type your comments
and submit, and then if you're lucky you go double-check your own update and
notice you demoted the bug back to P3 before your manager does :)

So I doubt this is new info, but is there any argument that users wouldn't want
this case fixed?
I don't think there's a single right way to do this.

I think the best solution is to let users force forms to always reset with a
setting in prefs.js or user.js.
(don't know what I was thinking rambling about this in bug 133946)

The whole dataloss argument here is due to the fact that visible form fields
remember their values on reload, while hidden form fields get new value from the
reloaded page. This seems awfully wrong. How hard would it be to make hidden and
visible form fields behave the same on reload? That would fix the situation of
incorrect data being submitted, regardless of what behavior (to restore or not)
is eventually decided upon.
That would basically involve moving form state restoration out of frames and
into content (which should probably be done on general principle).
*** Bug 235929 has been marked as a duplicate of this bug. ***
(In reply to comment #153)
> How hard would it be to make hidden and
> visible form fields behave the same on reload? That would fix the situation of
> incorrect data being submitted, regardless of what behavior (to restore or not)
> is eventually decided upon.

I think this is not true. Consider the following:
You have a table, and every table-cell do have some text in it. The user
representation of some data.
corresponding to every table-cell, you have a hidden field with the machine
representation of the same data.

With some javascript it is possible to change the text in the table-cell and
also the hidden field value is changed.
(This is the situation where i found this bug.)

Now the automatic value refresh of the form cant know about this, so on reload
the table-cell shows the correct value, while the hidden field value is set to
the remembered value.

If the developer set the value="" parameter of an input-element this value
should be taken.
I think the only situation where the automatic is wanted, is when pressing the
back button, and then, not only the form should be restored, the complete
dom-tree should be restored.

Some of you might dislike javascript, but in an full blown business application
it is needet like a bit of bread.
after reading all these comments in detail, i found the solution by adding
autocomplete="off" to the hidden fields
works in my case too :-)
*** Bug 224041 has been marked as a duplicate of this bug. ***
*** Bug 237945 has been marked as a duplicate of this bug. ***
*** Bug 241660 has been marked as a duplicate of this bug. ***
what's the status of getting this fix.  as web developer and user i found this
to be a huge bug.  i don't understand why anybody would not want a fresh page
loaded.    
I apologize if I missed the following variation of this issue in perusing the
150+ replies that preceded this one :-) If I did, maybe this will provide a
clearer example.

I have a form created by JavaScript. The purpose is not to send data back to a
server, but store it in a JavaScript object (which writes the form when it
displays itself). The form's text fields are filled from the object's initial
properties, and they have an "onChange" event to capture and store user-entered
data.

On either refresh or hard-refresh of the page (Mozilla 1.6, 1.7rc3, Mac OS X
10.3.4), the JavaScript object's properties have been restored to their initial
values, but in the form these values are overwritten by the previous
user-entered values, and the object is now out-of-sync with its display.

One person suggested that, if the user-entered form values are restored, the
entire DOM of a page should be restored, too, which I think would fix this
issue. The other possibility might be to treat this form-filling as if a user
had actually filled out the form immediately after load, and so fire the
onChange event in the same way.

For what its worth, I personally would want a hard-reset to return a page to its
initial state, while a soft reset should really be for display issues, and so
retain all previous-modified state information.
For a perfect example of why the current behavior is wierd/bad/immoral:

1) Browse to http://www.tumyeto.com/main.php
2) Notice in the "Rider Profile" box that the name in the dropdown matches the
currently displayed rider.
3) Hit reload.
4) Now the rider name in the dropdown is out of sync with the rider being displayed.
5) View Source, find the rider profile box, you will see that Mozilla is
deliberately DISOBEYING THE SOURCE CODE of the file it is rendering.
Just so we're clear--If you hold down "shift" while clicking reload, the rider
profile and drop-down do match.  

It's only on normal reload that the drop-down selection is forced by mozilla to
the pre-reload value.

But this is a good example of why the current behavior sucks.

At the very least, mozilla needs to obey tag attributes like:

value="" 

and 

selected = "selected"

  For a drop-down list, if there was no explicitly selected option, it would be
ok (IMO) for mozilla to show the pre-refresh selection,  Same thing for other
form elements.

I think mozilla's current behavior is leaning just a little too far toward
convenience at the expense of solid design.  It's frustrating for web developers
who just want the browser to (pretty please) do what the valid html says.
Ladies and gentlemen, boys, girls, and wannabes:

Please stop adding comments to this bug that say "This is bad!" or "Why this is 
bad".  Yes, Mozilla developers know about the bug.  There are at least 50 
people cc'd on this bug (who all receive the same bugspam you do), who are all 
waiting and watching for someone to step up and fix this bug.  There are 165 
comments on this bug (counting this one).

To date, there have been ZERO attachments on this bug.  No patches, no 
testcases specific to this bug, nothing.

This bug is nearly four years old as filed.

This will be fixed when we have a volunteer contribute a patch, when that patch 
gets r+ and sr+, and when it's checked in.  Crying about the problem (duped 
over and over and over again) does not help solve the problem.

Is there anyone who is willing to accept this bug and start working on a patch?

For the serious developers on this cc list, I apologize for the bugspam.
*** Bug 248832 has been marked as a duplicate of this bug. ***
*** Bug 255418 has been marked as a duplicate of this bug. ***
Our problem on a page generated by a servlet with a number of checkboxes seems
to be resoned here also:

The page is reloaded, some checkboxes (all the same name but different values)
disappear but the same in order will be checked (no checked atrribute rendered!).

The former checked once values are not rendered again by the servlet. Lets say
they have been the third and fifth. After reload the third and fifth checkbox
are checked again (by Mozilla, does not happen on IE...) also having different
value attribues.
*** Bug 256823 has been marked as a duplicate of this bug. ***
*** Bug 239730 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0?
For Firefox 1.0PR on Windows: Hit Ctrl+F5 to refresh the page without the cached
form entries. It refreshed to the (source) selected options in my case.
For Firefox 1.0PR on Windows: Hit Ctrl+F5 to refresh the page without the cached
form entries. It refreshed to the (source) selected options in my case.
would need a patch and lots of testing for inclusion in aviary 1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0-
What is aviary?  Is that the new name for Thunderbird?
Aviary = Firefox + Thunderbird.

Aviary 1.0 = Firefox 1.0 + Thunderbird something.
*** Bug 262665 has been marked as a duplicate of this bug. ***
*** Bug 264043 has been marked as a duplicate of this bug. ***
*** Bug 265470 has been marked as a duplicate of this bug. ***
*** Bug 274795 has been marked as a duplicate of this bug. ***
*** Bug 263363 has been marked as a duplicate of this bug. ***
*** Bug 249972 has been marked as a duplicate of this bug. ***
*** Bug 283094 has been marked as a duplicate of this bug. ***
*** Bug 282030 has been marked as a duplicate of this bug. ***
At http://www.sff.tigerheron.com/

The Search SF&F box is a SELECT item in a form. It has the value "SF&F Books",
which is the first item in the list and the item specified as "selected" by the
code:

<select name="SearchIndex">
  <option selected="selected" value="Books">SF&amp;F Books</option>
  <option value="Books">SF&amp;F Young Adult Books</option>
  <option value="DVD">SF&amp;F DVDs</option>
  <option value="VHS">SF&amp;F VHSs</option>
</select>

On a page reload, the box displays "SF&F Young Adult Books", which is the
*second* item on the list and which is not specified as being selected. As
stated elsewhere, a Shift-Reload displays the correct item.
Flags: blocking-aviary1.1?
*** Bug 274746 has been marked as a duplicate of this bug. ***
This bug is INVALID (not WONTFIX).  Browsers going back to Netscape 1 (and
almost certainly NCSA Mosaic, but my memory fails me) have restored saved form
data on reload, but not on shift-reload.  See bug 293258 for a recent regression
in this age-old browser behavior.

Feel free to test Safari, Opera, and IE6 and either confirm compatible behavior
here or report bugs to those browsers' vendors.

When testing, beware form-bearing pages that use HTTP cache control to prevent
reloading from cache.

/be
Status: REOPENED → RESOLVED
Closed: 24 years ago → 19 years ago
Resolution: --- → INVALID
(In reply to comment #186)
> See bug 293258 for a recent regression

I meant bug 294258.

/be
Flags: blocking-aviary1.1?
*** Bug 295250 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
It seems self evident to me that if the rendering disagrees with the underlying
html, as is the case when the selected option of a select list is not in fact
"selected", this is a gross bug, which makes it impossible to create dynamic web
pages that behave properly and predictably on Mozilla.

--Frank Hanny 
fchanny@lbl.gov

Whatever comment 189 is talking about, it's not this bug.  File a new one with a
specific complaint and test case and reproduce-by steps.  Portentous assertions
in this bug are just time-wasting noise.

/be
Status: RESOLVED → VERIFIED
*** Bug 283205 has been marked as a duplicate of this bug. ***
*** Bug 305482 has been marked as a duplicate of this bug. ***
To comment 189: This is actual connected as indicated by Gavin Sharp who has made my bug 305482 duplicate of this one (see it for details). I still think it is not dupe but I won't kick with a horse.
*** Bug 322579 has been marked as a duplicate of this bug. ***
*** Bug 325706 has been marked as a duplicate of this bug. ***
*** Bug 349505 has been marked as a duplicate of this bug. ***
*** Bug 252691 has been marked as a duplicate of this bug. ***
*** Bug 338593 has been marked as a duplicate of this bug. ***
*** Bug 325360 has been marked as a duplicate of this bug. ***
*** Bug 357200 has been marked as a duplicate of this bug. ***
(In reply to comment #200)
> *** Bug 357200 has been marked as a duplicate of this bug. ***
> 

My original bug was related specifically to the radio buttons saving their disabled states in the Form Manager, although other form elements such as the submit button do not save their disabled state in the Form Manager. This is inconsistent, and in saving the disabled state of the radio buttons causes a problem. This is something that requires attention, and is not a bug relating to the greater principles of the Form Manager, just the saving of the disabled state of the radio button.
The idea that clicking reload should not put the page into the same state as when first loaded seems wrong to me. For example, in my app I have hidden form fields which are only manipulated by scripting. The scripts assume that the hidden fields are in a defined state (empty or initial value) until updated by the scripts. Clicking "reload" breaks this assertion - the javascript variables are all reset but the form data remains - and the scripts fail as a result. This is nothing to do with user experience since the fields are hidden (see bug 376294).

FWIW I observe form data being reset with IE6 when clicking the reload button.
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
Even after all this discussion I still think Firefox is WRONG to not clear form elements on refresh. All of Opera, Chrome, Safari and IE clear form elements on reload for http:// URLs (and all except IE do for file://). I also have had problems with form state being out of sync with javascript state which is reset on reload, see my comment #202. Perhaps I'll enter a bug with a test case for that but it'll probably just be dup'ed against this one.
(In reply to comment #206)
> Perhaps I'll enter a bug with a test case for that....

Bug 465203
(In reply to comment #202)
> The idea that clicking reload should not put the page into the same state as
> when first loaded seems wrong to me. For example, in my app I have hidden form
> fields which are only manipulated by scripting. The scripts assume that the
> hidden fields are in a defined state (empty or initial value) until updated by
> the scripts. Clicking "reload" breaks this assertion - the javascript variables
> are all reset but the form data remains - and the scripts fail as a result.
> This is nothing to do with user experience since the fields are hidden (see bug
> 376294).
> 
> FWIW I observe form data being reset with IE6 when clicking the reload button.

My IMHO is that remembering form element values upon reload is COMPLETELY INCORRECT!

Do you understand that you put the reloaded page into some unexpected INCONSISTENT (!) state? Just because that's nor the OLD version of page nor its NEW version. That's some another "MIXED" version.

The obvious example of harm caused by this inconsistency is in Bugzilla's behaviour. All bug edit forms contain delta_ts (timestamp) hidden field used for edit conflict detection. So, when you submit an OLD version of form, you'll get a warning about "Mid-air collision". But if you use Firefox and reload this form, delta_ts IS UPDATED, but other form fields ARE NOT. So when you submit this "NEW" (but really "MIXED") version, you overwrite changes made by other people and there's NO MID-AIR COLLISION!

I'm shocked! The bug lasts NINE YEARS, has 23 votes (with my one), has many duplicates, and the resolution is "invalid". :-((((
Re: Brendan:

"Browsers going back to Netscape 1 (and almost certainly NCSA Mosaic, but my memory fails me) have restored saved form data on reload, but not on shift-reload."

1) Just because (if) many browsers have done things historically wrong does not mean they should continue to remain so.

2) Browsers that historically have done this have only historically done it to static pages that have not changed. Pages dynamically generated have not and should not exhibit this behaviour.

3) Frank Hanny said "It seems self evident to me that if the rendering disagrees with the underlying html, as is the case when the selected option of a select list is not in fact "selected", this is a gross bug..." and you said, in reply, "Whatever comment 189 is talking about, it's not this bug.  File a new one..."

Just because you didn't "get it" doesn't mean you should behave rudely. I understood what he was saying clear as day, he is right, and it *is this bug*. This bug which is not INVALID and should not be marked WONTFIX, because it's perfectly valid and needs fixin'.

To illustrate Frank's point:
if I write HTML that says:
<form>
Text: <input name="foo" type="text" value="Foo"/>
Choose: <select name="ba*"><option value="bar" selected>Bar</option><option value="baz">Baz</option></select>
</form>

Then when a user first gets to the page he/she sees:
Text: [Foo              ]
Choose: [Bar            [v]]

If a user then changes the text field to say 'BimBamBoom' and select 'Baz' from the drop-down, and *then reloads the page* the *HTML REMAINS THE SAME* but what is being rendered on the page is equivalent to if the HTML had said:
<form>
Text: <input name="foo" type="text" value="BimBamBoom"/>
Choose: <select name="ba*"><option value="bar">Bar</option><option value="baz" selected>Baz</option></select>
</form>

Note that therefore *what the browser renders* is *not* the value the person who wrote the page intended upon reload.

This is therefore a bug and valid. Please correct the status of this bug immediately.

Note to Vitaliy:
26 votes (not counting the affirmative comments that didn't vote) and ten years, now. One would think this would not be ignored.
(In reply to comment #213)

Dodger, if you change strings in form, Text->TextX, Choose->ChooseX, Bar->BarX, Baz->BazX, just before your Reload, as you know, you probably see display result like next.
> <form>
> TextX: <input name="foo" type="text" value="BimBamBoom"/>
> ChooseX: <select name="bar"><option value="bar">BarX</option><option value="baz"
> selected>BazX</option></select>
> </form>
It's done on purpose - to keep user's input in form upon "Reload", in order not to loose user's input in form by "Reload". 
It's concept and DESIGN of functionality named "Reload" of many browsers since initial, which is probably inherited from NCSA Mozaic.
Shift+Reload is for reload HTML page without keeping user's input in form, and this is also DESIGN of many browsers since initial, although name of functionality of "Shift+Reload" depends on browser.

(In reply to comment #213)
> Note that therefore *what the browser renders* is *not* the value the person
> who wrote the page intended upon reload.

Dodger, are you talking about next phenomena?
(a) When Web designer returns completely different <forms>'s of different
    id/name at completely different location in window at comletely different
    position in HTML structure, form content is restored in form(s) by "Reload"
    as usual, as traditinally.
    Then, dislayed result sometimes becomes different from recent Web
    desgner's thought.
    It's mainly by;
    - Reload is mainly for browser user's convenience.
    - Web designers usually don't understand functionallity of "Reload".
    - There is no way for server to know the HTTP GET is for which of Initial
      Load, Reload, Shift+Reload etc.
      And, there is no way to inhibit restoring of form data by "Reload" of
      browser which is for browser users instead of for recent Web designers.
      So, server side application basically can do nothing on browser's
      behaviour of "Reload" for browser user.
    - Browser user can't know "Shift+Reload" is mandatory or not in order to
      obtain display result which recent Web designer want to show.
    - Current "Reload" implementation doesn't care for such dynamic or random
      changes on form elements in an HTML between concecutive two HTTP GETs
      to absolutely same URL.
(b) When designer returns different SRC of <iframe> when "Reload" by user,
    or JavaScript changes SRC of <iframe> while loading of HTML by "Reload",
    the change of SRC is not reflected to rendering result,
    because <iframe> content is restored from history
    in order to keep last displayed URL in <iframe> by user upon "Reload".
Both are known issue for recent Web designers and bugs are already opened.

Vitaliy Filippov and Dodger, please don't add comment for complaints of "Displayed result by Reload is different from your thought or opinion" to this very old bug of next bug summary which is caused by user's misunderstanding of functionality of "Reload" of many browsers.
> Form elements don't reset upon manually reloading page
Please don't request to kill functionality of "restoring form data by Reload"  for many other browser users including me.
If it'll be killed, I probably loose my typed text frequently at many Web sites including B.M.O.

One of causes of above (a) is that current "Reload" simply restores form data based on sequence number in an HTML(probably can be said N of document.forms[N]). As many Web designers change id/name etc. when he sends different forms, care for id/name of form elements upon restoring of form data can be a solution. Form structure check is also a solution. Check of id/name/element-type of parent node of form may be a solution.

Anyway, if you are talking about issue like above (a) or (b), please search bugzilla.mozilla.org well for already opened bugs via Advanced Search.
I find that discussion of Reload vs Shift-Reload confusing.

I thought Shift-Reload is for telling the browser to refresh its cache, not for giving it permission to undo changes I've made in forms, which it should do anyway.  Speaking from my own usage patterns and experience -- it's not like I can claim to have been involved in the design of Navigator 1.0 or anything -- I don't expect the browser to persist my input on Reload.  I'm intentionally asking it to reload the page!

(Having the browser keep my input across back/forward is an entirely different matter: very useful, and important.  But not across Reload.)

Whatever.  It's pretty clear this bug isn't going to get fixed; the people who matter either haven't noticed it, don't think it's important, don't care, or don't think it can be reconciled with other behavior they find more important.  (It's certainly a real bug; I continue to see people post incorrect updates to an internal bugzilla, obviously due to this bug.)

The result of this, sadly, is that I mostly use Chrome instead of Firefox, so I don't really have to care either.
Maybe we are just busy elsewhere. It's easy to mix up other bugs' symptoms and blame them on this bug.

But bottom line, if Firefox is the only browser that saves form field data across reload but not shift-reload the I suppose we should go with the crowd. (Matt, will that get you back on Firefox instead of Chrome? Mail me, no need to comment here again.)

File a new bug please, this one is old and it has served its purpose. Also, the Reload button and gestures/modifiers for it are Firefox, not Core / Document Navigation. Please cc: Alex Faaborg for his user experience expertise.

/be
Perhaps the description of the new bug could point people towards (calmly) voting for or against a change rather than commenting endlessly ? Otherwise, history could repeat itself...
I do not consider this a bug. I rather like the way this works. If you fill in a form and then either reload the form or advance the form to the next page and go back, the form contents will remain. Holding the shift key when hitting the reload will clear the page contents. This greatly aids in debugging form handlers as you can move back and forth without retyping the form content each time.

The proper method to clear a web form is for the designer to use a "clear form" button. This clears the form properly and provides the user with an easy to understand reset mechanism.
I consider it a bug.

Reload should reload default values in forms - the original "load" loaded the defaults - the reload is repeating the first. One must assume that redoing something is as close as possible the original act repeated.

A practical objection is that I am using Ajax to calculate a price based on simple form variables such as number of people, I am coding in PHP.

I have PHP functions which take a array representing the values and names for a series of pull downs - so typically something that will give the user a choice of number of people 1 to 10, bound into this PHP is clearly defined defaults which are then represented in the usual fashion in the initial values of the form fields.

When PHP is outputing the page it calculates an initial price based on the initial or default form fields.

The Ajax functionality calls the same final PHP functionality although the code route is obviously different - this is the nature of Ajax. The calculations all end up in the same PHP code for reasons obvious to anyone concerned with code reliablity and maintainability.

The problem I have is that when I "reload" the page in Mozilla the form elements stay at the values that the user has changed them to whilst the calculated price defaults back to represent the default form values, there is
now a disparity between price and form data which is not present on (say) IE.

Non of the PHP code reads the form values - a moments reflection !! PHP is server side. Instead the initial calculation of price is performed solely in PHP because the form is written by PHP and so PHP is hierarchically higher and has control over the defaults or initial values for the form so this is fine as far as any sensible measure of coding standards. When the user creates an event by changing a form field then the usual Javascript/Ajax methodology ends up passing the modified form values to the same PHP code that performed the original calculation.

The method for updating the price via Javascript is not immediately useful for the initialisation of the price ( ie calculate using the default values for the form ) because for that we need an event to react to.

Ajax is useful but its messy and I try and use it and Javascript to a minimum.

It seems crazy to me that I have to add even more "pollution" by adding handlers listening for page load or page refresh in order to call Javascript functionality to read the "default but not really default because of the Mozilla bug" form values and perform the calculation - this shouldnt be necessary - PHP can do all of that cleanly and nicely with no event handlers provided I can be sure that at any stage that the PHP runs then the defaults that I specify and calculate upon are honoured by the browser.

It would be a whole lot easier if the most obvious, simple and honest meaning of the word "re-load" was being honoured here.

As I said at the start - loading a page does not depend on history - the classic meaning of "re-verb" is to do "verb" a second time in an identical fashion - of course language is usually bent to fit the purpose and when we say we are repainting the house we all know its ontop of an existing layer of paint and so not an indentical repetition but in software and science I would say that the meaning and intention of "re-verb" is understood to mean that wherever possible we do not deliberately change the outcome, there is an expectation of repetition.

As for the hassle of re-filling in form fields.

Non-professional users will suffer - but they also suffer if they forget to back up their work or dont set auto-backup - this is the nature of all computing, the unwary who are not protected by auto-save will always have the odd hair tearing session - some may learn some may not. Personally I very rarely type into any text box without at least copying the text into notepad or something else from time to time as a backup. 

Sympathy for those who suffer but corrupting and bending a clearly defined behaviour to fit another purpose is questionable. A proper implementation of "refresh the page but remember all I typed" will require proper design and follow-through with particular thought to technologies such as Ajax which will generally be trying to react to the form - dont change stuff under our feet!!!


Jonnie

Seasoned ( retired 20 year IT veteran working in the aerospace industries ).
Bug 465203 deals specifically with the issue of javascript vs form state not being maintained in step across page reloads in mozilla. The conclusion there is that this is also the case in other browsers when using the forward and back buttons. Therefore code that relies on the two being in step can also break in other browsers.
What is the point of reloading if it does not re-****-load the page?

Reload means to load again. Like the first time.

Refresh means "give me the page fresh". Like it was the first time. Without my clutter all over it.
to keep input (hidden as well) field updated, add autocomplete="off" to input tag
I've encountered what might be an odd variation of the general issue discussed at such length here.  I created a web page with a disabled-by-default button on it (specified in the HTML as the page loads).  The user is allowed to enable the button only under certain conditions.  Well, if the button has been enabled, and the overall page is refreshed, it is STILL enabled!  Except that I want it to be disabled until the user qualifies to enable it.  There is a fairly simple local fix, of course, because I already have an "onload" event handler for the body of the web page (just added a bit of code to disable the button) as part of the JavaScript page-initialization.  It is still annoying to have had to do that just because of a "by design" choice made by FireFox developers, when it wasn't necessary for IE or Chrome or Opera.
Comment 225: You are describing bug 654072.
I'm not sure if this is pointed out, but one of the bad side effects of this feature is that:
- if you dynamically reorder input elements
- press F5
- content is loaded to wrong elements!
This is illogical. User presses reload and it doesn't reload. This is the only browser that does that. And it definitely shouldn't do for hidden inputs. User can't fix those. I don't always have the option to change html, sometimes only js or css and I have to make work arounds.
How is this still not fixed?!
This is happening to me  - two different versions of Firefox - I am also trying to have jQuery empty the fields, but it is ignoring it - it used to work fine.
It is a modal form that gets re-used on the page.
Autocomplete=off has no effect.

This is madness.
(In reply to Brendan Eich [:brendan] from comment #186)
> This bug is INVALID (not WONTFIX).  Browsers going back to Netscape 1 (and
> almost certainly NCSA Mosaic, but my memory fails me) have restored saved
> form
> data on reload, but not on shift-reload.  See bug 293258 for a recent
> regression
> in this age-old browser behavior.
> 
> Feel free to test Safari, Opera, and IE6 and either confirm compatible
> behavior
> here or report bugs to those browsers' vendors.
> 
> When testing, beware form-bearing pages that use HTTP cache control to
> prevent
> reloading from cache.
> 
> /be

I tested with Chrome and Safari and both DO NOT RESTORE DATA, the above comment is no longer valid.

In reading through the comments almost everyone wants Firefox to behave like Chrome and Safari does, that is to restore original page data and remove any data entered by the user.

Please make the "Reload current page" button in Firefox work like it does in the other main stream browsers.
I second the remark of Andy Bajka (comment 232).
In the development of our web-app, we are badly impacted.
This behavior causes us to add additional code, just for Firefox, in our complete application to assure 'normal' behavior.
The restore of the form fields is also mostly incomplete, and the resulting behavior of the form unreliable.

It is a pity, because with the recent improvements of Firefox one would advise people to use it, if it were not for this bug.

I'm hoping you can fix it.
This is just making issues, When you turn autocomplete off the reload behavior is back to normal. But the main idea is not good. Why would you feel the input automatically without notifying the user. this makes it impossible to make a change to the inputs based on their value.
I also can confirm this bug in newest Firefox, and it has a big impact on working with any CMS. Fields can be accidentally saved with wrong data. It also autofills empty fields sometimes with some random data on any form on any page.
There is an React.js component package to handle this bug.
https://www.npmjs.com/package/empty-option

This is hitting me pretty hard. I have an unattended kiosk where users need to enter their credit card number. When using Firefox, (I have to support all modern browsers), the previous user's card number is persisted and can be used by the next person. It seems I'm going to have to manually clear the data on reload. I could see a scenario where security vulnerabilities like this go undetected since other browsers do not have this 'feature'.

See Also: → 1754458
See Also: → 1745640
See Also: → 1752250
See Also: → 1758206

Когда фикс ожидается?

Flags: needinfo?(htsai)
Flags: needinfo?(htsai)
See Also: → 1848982
You need to log in before you can comment on or make changes to this bug.