Open
Bug 539228
Opened 15 years ago
Updated 2 years ago
Firefox remembers form contents based on order instead of on id or value (form state restoration)
Categories
(Core :: DOM: Forms, defect)
Core
DOM: Forms
Tracking
()
NEW
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.
Updated•15 years ago
|
Component: Location Bar and Autocomplete → Form Manager
Product: Firefox → Toolkit
QA Contact: location.bar → form.manager
Comment 1•14 years ago
|
||
I can confirm that the bug is still there in 3.6.13 on Linux.
Comment 2•13 years ago
|
||
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.
Comment 3•13 years ago
|
||
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
Updated•13 years ago
|
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
Updated•13 years ago
|
Comment 4•6 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•3 years ago
|
Component: DOM: Core & HTML → DOM: Forms
Updated•3 years ago
|
Severity: normal → S3
Priority: P5 → --
Updated•3 years ago
|
Updated•2 years ago
|
Comment 5•2 years ago
|
||
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)
Comment 6•2 years ago
|
||
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.
Description
•