Closed Bug 46845 Opened 25 years ago Closed 20 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

(6 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 → 20 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
See Also: → 1943000
You need to log in before you can comment on or make changes to this bug.