On some pages with forms, when you press Reload in Firefox, the page reloads but Firefox keeps the original contents of any elements (although it does update or reset other form elements, including hidden ones). This can leave forms in an inconsistent state. Anyone know why it does this, and whether it’s possible to set caching-related or other HTTP headers to stop it? Shift-Reload seems to sort out the problem, but people won’t necessarily know or remember they need to press that.
I can’t find anything by searching – all I find when searching for “Firefox clear textbox” is people asking thinly-disguised “how do I conceal my pr0n-surfing habit from my girlfriend?” questions…
It’s done that way on purpose so if you tap the refresh button you don’t lose your work. There’s an entry in Bugzilla somewhere that’s been WONTFIXed asking for a regular refresh to always reset the form entirely. Basically it’s a backwards-compatibility thing — every browser since NS1.0 (maybe even Mosiac) has done that.
Dynamically-generated pages don’t even reset themselves, though if the expiration is set to 0 and you hit the back button it will give you a fresh form. Also, if the form itself changes (add or remove elements, change the action, etc.) the for will reset on a reload. I haven’t tested it, but setting the form name to something random (assuming you don’t need the name for JS access) might just work. Like <form name=”f<?=mktime()?>”> in PHP.
As you said, forcing a refresh clears the form, and resetting it does too. Would something like <body onLoad=”document.myForm.reset()”> do what you want (again, not tested)?
But, er, what is the Refresh button for, then?
I think the problem we are seeing is that it’s inconsistent – it keeps text fields, but reloads and replaces hidden form fields. So the “change conflict” detection breaks.
That’s all very interesting, but how do I conceal my pr0n-surfing habit from my girlfriend?
Honestly, not a whole lot 99% of the time. Unless you get a transient error or you’re trying to keep a server-side session alive, the refresh button is almost always useless. And in most of the cases where it does do something, hitting it is harmful (i.e. resubmitting a payment form). But that’s more a reason to do away with the thing entirely, not an answer to your question.
Like I said, as far as I know it’s just tradition and backwards-compatibility.
I haven’t paid much attention to hidden fields — I tend to get those right the first time when building pages :) — so I don’t know about their behavior changing. Personally I think that if a hidden field changes the form needs to reset. Given what you’ve said that’s not the case and I’d consider it a bug. But since my programming knowledge is limited to JS, ASP and PHP I’m not in a position to fix it.
At a guess I’d say that the reason forms behave that way is because it fits the 90% case — most people don’t want to retype everything if they refresh the page (asuming they even know what the refresh button does) — so if nothing they have access to changes, the browser leaves it. There’s probably some logic buried somewhere that tells you what causes a form reset, but I doubt it’ll tell you why — all the people who knew probably left years ago.
The fact that hidden input state is not restored is a bug, imo, probably arising from the fact that state restoration uses the frame tree….
Did you file it?
On the use of the refresh button: The only time it was ever really part of my browsing experience was when I was on dial-up and would hit the “Stop” button on pages that took a long time to load. Then if I wanted to see an image or something that had not loaded, I would hit refresh.
Boris: hidden input state _is_ restored – that is, if I reload, all the form fields (including the hidden ones) except the textfields are reloaded from the server, but the textfields are preserved. This means the hidden stuff which would detect a mid-air collision doesn’t work any more. Flow (this is not Bugzilla):
Result: Fred’s edits appear twice and Joe’s are nuked, because the reload kept the textfield the same (i.e. one copy of Fred and no Joe) while updating the hidden fields. So when Fred pastes and the submit then goes through, you get two copies of Fred and Joe’s edit is lost.
There was a discussion about this recently in m.d.a.firefox (reload vs. shift-reload in general, not specifically form fields)
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/90bc9cabfdae53cc/cd9b934592cdc24c
I’m not sure what you mean by “Fred’s edits appear twice”. Also, because of the fields-not-resetting thing, Fred shouldn’t have to paste his original text over Joe’s because Gecko should keep Fred’s text.
If you wanted to force the form resetting behavior, bugzilla could change the field names each time a change is made (“short_desc5” instead of just “short_desc” once the summary has been changed 5 times).
Gerv, “restore” means “set to the value it had before the reload” in this context. So in fact you’re saying that hidden inputs are not restored.
Shift+F5
With some trial-and-error testing, I’ve found that sending the Cache-Control: no-store HTTP header will make the refresh button act the way you are hoping.
But by the sound of your flow example, I think this will still not help you, because when Fred gets the mid-air and goes Back, his previously entered form data will not be there to be copied to the clipboard. The Cache-Control header took care of that too.
I think your design is flawed. Perhaps you could do this:
1) Fred submits and gets a mid-air
2a) The server returns a textarea containing the data which was committed to the database which caused the mid-air
2b) The server also returns the block of text Fred was trying to submit.
3) Fred copies the relevent part of his submission from (B) to (A) and resubmits.
See bug 46845. The bug is resolved INVALID – see comment 186.
Uh, since when is the Refresh button mostly useless? Haven’t you ever looked at a page that updates frequently, like a news site or a web forum?
Just in case Justin’s comment was in response to mine: Yes, I read the news and some web forums; I just don’t live on them. I have to work at work :) My usage is to open up the threads/articles that interest me, read them, then come back a couple hours later. So that’s not an F5 for me, it’s retyping the address. It never occurred to me that people would sit and refresh a forum page constantly, even though I kinda-sorta did the same thing with Usenet when I first got to college in ’94.
One other time when F5ing is useful: When a regularly-updated comic is getting close to its update time and the “refresh monkeys” start banging away at the server trying to see the new issue. This is still bad, but it’s bad for the server admins, not the user.
And thanks to Uri for spotting the Bugzilla entry. I remembered seeing the bug a while back, but got the details wrong. (As you can see, I also couldn’t be arsed to research it myself.)
> But, er, what is the Refresh button for, then?
How long have you been using the web?
The refresh button hasn’t really been necessary for most users for the better part of a decade, but in the early days of the web it was much more necessary, because back then pages that were updated on the server on a minute-by-minute basis (e.g., web chat facilities) did not automatically reload. At some point the tag was introduced to HTML (circa version 3 IIRC), and more people became aware of the Refresh header, and after about 1996 it was seldom necessary to use the reload button. Of course these days the major browsers support the DOM and asynchronous retrieval, so even Refresh will hopefully be going the way of the blink tag eventually.
Why the Reload button is still on the toolbar by default in modern browsers is another question. End users don’t understand it anyhow. Obviously it should still be an option for users who want it, but in the default configuration it should probably not even be there. (If it were me I’d take Forward and Home and Stop off by default too. Power users who actually have a use for them can always go into Customize and add them.)
Reload is useful for web developers, though. Make a change to the source, Alt-Tab, Ctrl-R, and see the result. Alt-Tab, make another change, …
> At some point the tag was introduced
The <meta> tag. (Forgot to encode the angle brackets as entities.)
Developers use the reload button every ten seconds!
Im seeing the hidden inputs ~not~ resetting. They are not even in a form, i just use them to hold local DHTML variables. That can be problematic.
I have created a flash slideshow of photos with lightroom. I looked at them a few times, them modified it with new photos, but I still only see the old ones! With IE if this happens I do a ctrl-refresh and it’s fine. With firefox I have tried reload, shift reload, F5 but none of them get the new photos. I did it once by deleting all the hidden cached files, but that is a bit extreme everytime a page is updated.
Can anyone help please?