Can you link to a page demonstrating this problem?

Firefox may retain and redisplay cached form field values when redisplaying a page, regardless of whether the input's are in a standard HTML form. If you want a reload to default the fields back to their original values, you could try preventing Firefox from caching the page -- some developers have said this is difficult because Firefox is rather stubborn about flushing cached pages -- or hook a different event (pageshow) to clear the fields back to default values. More info in this article:

https://developer.mozilla.org/Firefox/Releases/1.5/Using_Firefox_1.5_caching

Thx for the answer. Te page is not restored from cashe. Developer tools, gives a 200 return code for the php-script, and 302's for .css and .js files. As indicated by attached image, the input simply does not reflect the lines value, but displays what the user typed at the previous visit. I do not want to revert to defaults. The php-script actually formats the previous input - like zip, CPR and phone numbers, to a "standard". Currently developing the site - reload will be nescessary if visitor makes faults or does not supply needed information. (Tampering with browser settings, is not an option to solve the problem!) And it is all happening after a login, with data in a database. So it is not really possible to give a link, at this time. Can maybe try to set up a demo sometime in the near future, if needed.

Birger52 said

As indicated by attached image, the input simply does not reflect the lines value, but displays what the user typed at the previous visit.

Okay, I think I see. The user entered the post code without the hyphen and submitted the form. The server sent back the same page* with an updated value attribute for the input (with the hyphen), but Firefox displays the originally input value (without the hyphen).

* By "the same page" I mean the identical URL.

Since it is a text input, there's no reason for Firefox to omit the hyphen -- unless it is displaying the input from a cached version of the page.

This is thinking out loud and not a solution yet:

What if you reset the form fields to their values in the source code from the Web Console?

document.getElementById("refcpr").form.reset();

https://developer.mozilla.org/docs/Web/API/HTMLFormElement/reset

That wouldn't be available if you do not use form tags. In that case you could reset individual fields as follows:

document.getElementById("refcpr").value = document.getElementById("refcpr").getAttribute("value");

This does the trick. Thx. Already have an onload event handler on window, so simply reset all input lines in that. The problem exists for selectors as well - had to set selectIndex through js, to actually make it display the selected option.

I do understand (I think) the idea behind this bug - it is a service to the visitor, not to have to retype everything, if a form is discarded for some reason. But it is a serious flaw, that the programmer/designer has to add ekstra programming and even fileds in the form, to actually have the display look like it should. Must be the programmers responsibility to save what data needs to be saved, and supply that serivce to the visitor - it is not the browsers...

I started creating a demo page to see whether I could re-create the problem, but using either a "GET" or "POST" form submit (submit to self), I got blank fields back, so I don't know what's happening with your page.

I always use POST - but rarely actually a form, tho in this I could have - submit through AJAX. It gives more control and and more options in handling return values. That might be the cause, even tho, the way the page is reloaded, sholdn't affect, the content...

Let me see if I understand this: you create an AJAX request with the data from the INPUTs and POST that, and when you get the response text, you replace or modify the INPUTs without reloading the page?

No. Usually, I do, and then there is no problem setting new data to an input through js.

The page that gives these problems, IS actually reloaded from the server - and doing that, inputs does not show the programmed values, but what was in the lines, before the submit.

It is supposed to be a combination of a signup page, and a page showing data for the signed up. Diffenece will then be hiding lines, that the user can not change after signup (username, password, category etc.), and disabling those that contains data. Correcting user data, will then be possible by simply enabling or disabling individual lines. Complete reload will only be done after signing up. And that is where inputs does not show formatted data, but the ones submitted.

Hope this explains... ;)

I don't understand the difference between your reload and complete reload, but a reload definitely is different from a form submission. Let me give you an example.

On this forum, if you type some text into the reply textarea, you will get different results from these:

• Ctrl+r => Standard reload, text usually is maintained
• Ctrl+Shift+r => Reload bypassing the cache, text should be cleared

I tried to make a simple site to reproduce the problem, using same scripts and php where possible, but I can't. (http://2.110.131.16/tests/mozinput/) [can send you the files for that, if interested - but PHP is my own homecooked OOP, so may not be readily understandable...] Then tried to remove the js reset from the site where I am working with it - and it still creates the problem. (Text in inputs not the same as in value of the lines, when page is reloaded). No PHP error, HTML is according to standards, and no js errors. Don't really understand why this is happening.

To the question about reload - I reload with the js location objects reload function: location.reload(true); parameter is forceGet - setting it true, forces a reload from server...

How are you "reloading" the page? As mentioned earlier, Firefox does preserve form values on a regular reload (or using the back button to return to a form after submitting it), unless anti-caching headers bar it.

Whoops, our posts crossed.

location.reload(true) should clear user field input.

Hopefully you can build a demo of the problem so it can be reviewed to determine whether there's a bug in that function.

)

As mentioned above, I did try to, but can't reproduce the problem with a single input.

Actually, removing the fix (resetting inputs), the "bug" is no longer present.

Don't know what I have done. I did not know the diffence between Ctrl+R and the shift version - that may be (have been) the problem... Pretty sure it also exised by relod from js, tho. But it does not now....

Just FYI: Doing something entirely different, but having the exact same problems - even with hidden inputs. Sometimes reload does one thing sometimes another. Seems like, when things go "wrong" or unpredictable, is after singlestepping js with the build-in tool.

This one I'll berewriting to use divs hidden with CSS. User may reload - and the results can not depend on wether FF keeps old values or not.

Birger52 said

User may reload - and the results can not depend on wether FF keeps old values or not.

To take control of the page on reload, which may behave differently in different browsers and with different cache control headers, check the article I referenced in my first reply:

https://developer.mozilla.org/Firefox/Releases/1.5/Using_Firefox_1.5_caching

Thx. That actually explains a lot.