Back button leads to shifted form values if input element was inserted in JavaScript




7 years ago
3 years ago


(Reporter: Olivier Jaquemet, Unassigned)


6 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)




7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

In short : 
1. submit an HTML form, which contains :
- two checkboxes (the first one checked by the user)
- a textfield input, inserted in javascript, after DOM load, before the two checkbox in the DOM hierarch
2. go back with the back button

In details : 
1. Open Firefox (tested with Firefox 6.0) 
2. Access the following test case :
In the results pane, it contains a form, with 2 checkboxes, and 1 textfield inserted in JavaScript (before the 2 checkboxes in the DOM hierarchy).
3. Check the *first* checkbox,
4. Submit form by clicking the submit button "OK",
5. Go back in browser history using the back button.

The bug looks very similar, but does not mention any JavaScript manipulation, which is clearly at the origin of the bug described here.
Indeed, performing the same test without javascript insertion does not reproduce the bug, see test case

Actual results:

The first checkbox should be checked.

Expected results:

A shift has occured and the second checkbox is being checked instead of the first one.


7 years ago
See Also: → bug 140697
I can reproduce this Behavior back to Firefox 2 Branch.
Nonetheless, it's WFM in Chrome/Opera.
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Whiteboard: [dupeme]

Comment 2

7 years ago
Thanks to all for your work on this issue (and same remark for all other great work you do for the mozilla foundation! :)

Just for my personal knowledge : at which time the status of a bug leave the UNCONFIRMED status in the mozilla bug processing workflow ? And who is in charge of various steps (reproduce, fix, test, validate, ... ) in the mozilla foundation ?
I suppose it is related to the bugzilla bug's life cycle But I could not find relevant information.
Just wait for Bug 660549 to get fixed on a Nightly and see if your Issue persists. If "no" this may end as a Dupe. If "yes" this can be set to "New". Thus UNCONFIRMED is okay for now. Just don't over-interpret the Status Field's Meaning ;-).

Comment 4

6 years ago
Isn't this a dupe of 677430 ? Anyway, 660549 should go first I guess.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 ID:20140923194127 CSet: 63ce8133f1cc

WFM with:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20150320202338 CSet: df45b1c67169
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 ID:20150330030203 CSet: 6082a98d3861

=> dupe to Bug 737851 (via Bug 660549)
Last Resolved: 3 years ago
No longer depends on: 660549
Resolution: --- → DUPLICATE
Whiteboard: [dupeme]
Duplicate of bug: 737851
You need to log in before you can comment on or make changes to this bug.