1760911 - The cached "checked" property of a checkbox is applied to the wrong element on reload

Status: RESOLVED DUPLICATE of bug 1752250

(Core :: DOM: Forms, defect)

Description

[Frank Forte]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

1. Visit https://gamma.bakacafe.com/sandbox/checkboxes.php

2. Check the 10th checkbox in a list of check boxes, then clicked "submit" which submitted the form via Ajax.

3. Refresh the page.

Actual results:

When refreshing the page, the list was different (as was the ETag for the page). This is expected since other users can add items to the list, and the list is also re-ordered to show checked items at the top..

In this example, the 10th item (with value 10) became the first item at the top of the list. It has checked="checked" and shows as checked (correct).

The 9th item (with value 9) became the 10th item. This one does NOT have checked="checked", yet Firefox shows it as checked (wrong)

This is catastrophic: when a user makes more updates on the page and clicks submit, this will save the WRONG information!!! The wrong item is now checked which could be giving a wrong permission, or giving a discount to a wrong account in a production application.

Expected results:

Firefox should not randomly autocomplete a check box that has a different id and value from the one that was checked before the page was refreshed.

If the HTML of the page has changed, especially the ETag, then autocomplete must not run for any input. The context is different and there is no way to know if the inputs will be in the same order or if the values will even mean the same thing. The user must re-fill the form to be sure.

For this example (https://gamma.bakacafe.com/sandbox/checkboxes.php) any check boxes or radio buttons with the attribute checked="checked" should show as checked. Any that do not have this attribute should be unchecked. I assume the same issue could happen for radio buttons.

If a "settings" page in a web application already fills default values, autocomplete should not interfere and cause users to save the wrong values!

This needs to be a high priority fix. Web developers won't even know that wrong information is saving, and others are being blamed for entering the wrong values.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Edgar Chen [:edgar] (OOO untils 09/01, slow response)]

We should not restore form if the page has a no-store header, patch in bug 1752250 should also fix this.