1752849 - Data corruption because of cached inputs

Status: UNCONFIRMED

(Core :: DOM: Forms, defect)

Description

[martin.vasel]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

Create a simple HTML Form with inputs:

<form action="">
<input type="text" value="123" />
<input type="button" value="reload 1" onclick="location.reload()" />
<input type="button" value="reload 2" onclick="location = location" />
</form>

Now change the value of the input and reload manually or press the buttons.

Actual results:

Manual reload and button 1: The input has the changed value, not the given value by the html.
Button 2: The input has the correct value.

Expected results:

The input should never be cached, because this can triggers some data corruption. Some forms are based on session values and reloading pages, but with another context, so the inputs are not reloaded and have wrong values.

I saw similar bugs, 11 years ago (https://bugzilla.mozilla.org/show_bug.cgi?id=654072) and 13 years ago (https://bugzilla.mozilla.org/show_bug.cgi?id=520561), but I never run into this issue before and it seems that the problem is getting worse with such a simple example.

Another popular solution seems to disable autocomplete attributes an all inputs, e.g.

• https://github.com/turbolinks/turbolinks/issues/536
• https://github.com/pradosoft/prado/issues/642

Comment 1

[Henri Sivonen (:hsivonen)]

Interaction of forms and cache, needinfoing peterv.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

This is intentional, to prevent data loss. You can use autocomplete=off on the input to disable this.

Comment 3

[martin.vasel]

Data corruption should not be intentional. I understand, what Firefox is trying to do, but it's terrible in many cases. We already have the window beforeunload event to prevent data loss. Something like this could be triggered by Firefox instead. As we already use this event, it's even worse: a message tells the user that the data will be removed when reloading, but that's a lie.

I already said that autocomplete=off seems to be a popular solution, but it's a just a workaround for people who knows this bug and it removes the feature to autocomplete inputs on new entries.
The company where I work has a different solution for inten web applications: Drop Firefox support. It's a faster solution, but it makes me realy sad.

Comment 4

[Edgar Chen [:edgar]]

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). I guess you run into this because of the regression, could you try that page where you report this issue with latest Night again? Thanks!