Open Bug 539228 Opened 13 years ago Updated 19 days ago

Firefox remembers form contents based on order instead of on id or value (form state restoration)

Categories

(Core :: DOM: Forms, defect)

defect

Tracking

()

People

(Reporter: michiel, Unassigned)

References

()

Details

(Whiteboard: DUPEME)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7

I have a web app that allows you to select some items from a list and then press a 'do stuff' button. 
The list is refreshed every x minutes by means of a <meta> header. 

The problem is, in Firefox, if the refresh comes the form remembers the checkboxes that were ticket. Apparently it does so based on the order of the boxes of the form and not on the id or value of the boxes. 

Example: you have a list of fruit:
o Apples
o Bananas
o Oranges

You select Apples and Oranges. The refresh comes, it adds Grapes between Bananas and Oranges.
The expected behavior would be that Apples and Oranges stay selected.
The observed behavior is that Apples and Grapes are now selected.

The issue is of course that if you click the 'Do Stuff' button just before a refresh, or just in general are doing some research while making your selections, you might end up doing stuff on fruit you did not select.

Reproducible: Always

Steps to Reproduce:
1. go to the URL http://beefreeit.nl/cgi-bin/fruitform.pl
2. Select bananas and lemons
3. Wait until the refresh comes

Actual Results:  
Some random other fruit, in the positions of the old fruit, is selected

Expected Results:  
the form is refreshed, but the same checkboxes for bananas and lemons stay selected.
Component: Location Bar and Autocomplete → Form Manager
Product: Firefox → Toolkit
QA Contact: location.bar → form.manager
I can confirm that the bug is still there in 3.6.13 on Linux.
This is still a problem in firefox 4.01 
A good description of the result is found at http://www.ryancramer.com/journal/entries/radio_buttons_firefox/

The result is that anytime javascript dynamically changes or updates an element with radio buttons, the "checked" attribute is ignored at least in the rendering.
I'm mostly certain this has nothing to do with the form manager. I think this is actually related to how session history serializes the form state.
Status: UNCONFIRMED → NEW
Component: Form Manager → Document Navigation
Ever confirmed: true
OS: Linux → All
Product: Toolkit → Core
QA Contact: form.manager → docshell
Hardware: x86 → All
Version: unspecified → Trunk
Component: Document Navigation → DOM
QA Contact: docshell → general
Summary: Firefox remembers form contents based on order instead of on id or value → Firefox remembers form contents based on order instead of on id or value (form state restoration)
Whiteboard: DUPEME
Depends on: 662743
No longer depends on: 662743
See Also: → 166636, 662743
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Component: DOM: Core & HTML → DOM: Forms
Severity: normal → S3
Priority: P5 → --
See Also: → 1752250, 1760911
See Also: → 1780183

The severity field for this bug is relatively low, S3. However, the bug has 5 See Also bugs.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(htsai)

For now I'd think S3 still makes sense. We could bump the priority if we see (more) webcompat reports in the wild.

Flags: needinfo?(htsai)
You need to log in before you can comment on or make changes to this bug.