Firefox - Form Input values persist after page reload
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
People
(Reporter: support, Unassigned)
References
()
Details
Steps to reproduce:
Open a page;
Type text into visible input (for visible input) and programmatically for hidden input;
Reload the page:
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>
<body>
<form>
<input type="text" />
</form>
</body>
</html>
Actual results:
The form input values persist after the page reload.
We experienced the same behavior in the recently released Firefox v96 (actual for the most recent v97 as well):
https://bugzilla.mozilla.org/show_bug.cgi?id=520561
It seems that this issue sometimes appears/disappears between different older Firefox versions. It was discussed several years ago here: https://stackoverflow.com/questions/2486474
This behavior change (v96) is especially critical for the ASP.NET Forms forms/pages where the state is stored within hidden inputs. As a result, the previous page state (input values) is explicitly restored after the page reload and does not match a new state that is generated from a server (which should be stored within hidden inputs). This issue is actual for visible inputs (text, etc.) as well.
This issue can be reproduced with a piece of pure HTML page markup.
Expected results:
The form input values should not be preserved after the page is reloaded (at least without a special trigger/marker).
Please clarify the following points:
- Is this persistent input behavior stable for further Firefox versions? Will it be reflected in the documentation?
- What is the proper way to deal with this behavior on logic forms (where the "autocomplete" attribute/behavior is useful)?
Any other comments/guidance would be appreciated.
|
||
Updated•3 years ago
|
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 1•3 years ago
|
||
It seems that this issue already exists since v80+ (not since v96+).
|
|
Reporter | |
Comment 2•3 years ago
|
||
According to our experiments, it appears that Firefox already does NOT preserve the "__VIEWSTATE" hidden input value (and may be the other inputs with the known/predefined ASP.NET inputs ids/names). Would you please confirm this?
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" />
If so, if there is any chance to extend these known ASP.NET inputs, especially NOT to preserver the "__EVENTVALIDATION" value on refresh:
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" />
|
|
Reporter | |
Comment 3•3 years ago
|
||
Some clarification regarding the ASP.NET hidden fields:
it appears that Firefox already does NOT preserve the "__VIEWSTATE" hidden input value
This is NOT exactly true:
Firefox restores hidden fields values, which are (re)set programmatically, but does NOT for those, which come with the initial page rendering.
As a result, (at least) two system-based inputs, which depend on each other, are not properly restored via the Firefox input "autocomplete" behavior and breaks the page integrity.
|
||
Comment 4•3 years ago
|
||
Interaction of forms and cache, needinfoing peterv.
|
||
Comment 5•3 years ago
|
||
(In reply to DevExpress Support from comment #0)
This behavior change (v96) is especially critical for the ASP.NET Forms forms/pages where the state is stored within hidden inputs. As a result, the previous page state (input values) is explicitly restored after the page reload and does not match a new state that is generated from a server (which should be stored within hidden inputs). This issue is actual for visible inputs (text, etc.) as well.
Hi reporter, we recently found a regression on 96 where we always restore form even on a page with a no-store header.
And the issue is fixed on latest Nightly (bug 1752250). Does ASP.NET Forms forms/pages still see this on latest Nightly? Thanks!
|
|
Reporter | |
Comment 6•2 years ago
|
||
Does ASP.NET Forms forms/pages still see this
Yes. Consider the following scenario: there are two hidden inputs on a page, and both come from the server (initial rendering) with unique values.
The result is consistent on the first load:
hidden_input_1: unique_value_1
hidden_input_2: unique_value_2 (based on unique_value_1)
Then, the "hidden_input_2.value" property may be changed/reset programmatically (even using the same value - "hidden_input_2.value = unique_value_2").
The result is inconsistent after a reload:
hidden_input_1: unique_value_3
hidden_input_2: unique_value_2 (it is no longer based on "unique_value_1" and is now restored via autocomplete; like it works for any visible input when it is set by the end user).
The only way to make this pair consistent again is to reset "hidden_input_1.value = unique_value_1" (i.e., to make it work via autocomplete later).
Would you please clarify if this is expected behavior for hidden input(s)? Is making two hidden inputs consistent an acceptable way to resolve the issue?
|
||
Comment 8•2 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #7)
Back to peterv.
Since Adam has been working on Forms for a while, I think we can forward this NI to Adam for some help. :)
|
||
Comment 9•2 years ago
|
||
It would be nice to have an actual testcase that shows the issue.
|
||
Comment 10•2 years ago
|
||
So the main issue here is the persistence of state for hidden inputs, right? That does seem like something that should be fixed.
Does setting autocomplete="off" have an effect in this case?
|
|
||
Updated•2 years ago
|
|
||
Comment 11•2 years ago
|
||
A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.
For more information, please visit BugBot documentation.
Description
•