Closed Bug 1322455 Opened 3 years ago Closed 3 years ago

Clone of unchecked input becomes checked if the node has the checked attribute

Categories

(Core :: DOM: Core & HTML, defect)

51 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla53
Tracking Status
firefox50 --- unaffected
firefox51 + verified
firefox52 + verified
firefox53 + verified

People

(Reporter: lb1.3, Assigned: hsivonen)

References

()

Details

(Keywords: testcase)

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161202091213

Steps to reproduce:

I checked the serialized value of checkbox that had been unchecked:

As a simple example:
http://jsfiddle.net/0h0x9wLz/
Check the checkbox and it should alert alternating "" (no check) and "Checkboxvalue=on"

Unfortunately whenever an originally-checked checkbox is unchecked, this still acts like it is checked:
alert($('form').clone().serialize()); always alerts the same thing as you check it and uncheck it.




Actual results:

Rather than unchecking, a clone of the checkbox is checked as it has the checked=checked value.

On some Firefox system it is always showing checked in this example - Chrome and some Firefox installs seem to switch fine however.


Expected results:

It should probably do the same as in other browsers (and some versions of Firefox) and switch the checked value.
Keywords: testcase
Product: Firefox → Core
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0

I have tested this issue on Windows 10 x64 with the latest Nightly (53.0a1-20161212030206) and managed to reproduce it.
When opening the URL provided in the description and checking/unchecking the checkbox the same message is displayed in the alert window "Checkboxvalue=on".

On the latest Firefox release (50.0) the issue is not reproducible.
I've performed a reggression, below are the results:
Last good revision: 18ff1472dae91c2b75e0ca843d52ad9a34c438cf
First bad revision: aadb57a9ddf83910a604f6be3b787fee661249db
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=18ff1472dae91c2b75e0ca843d52ad9a34c438cf&tochange=aadb57a9ddf83910a604f6be3b787fee661249db

Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1310865
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
[Tracking Requested - why for this release]:
Bad regression



Aryeh is away, so perhaps hsivonen you could take a look at the regression.
Flags: needinfo?(hsivonen)
Sigh. So deferring the uplift of bug 1310865 still didn't give it enough bake time to discover this. :-(

I'll take a look.
tracking this recent regression for 51 and up
Summary: Checked value is wrong in Firefox sometimes → Clone of unchecked input becomes checked if the node has the checked attribute
MozReview-Commit-ID: 1QxpiX02V0G
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
MozReview-Commit-ID: JbrpGAoB5tG
Attachment #8818856 - Attachment is obsolete: true
Attachment #8818864 - Attachment is obsolete: true
Flags: needinfo?(hsivonen)
Comment on attachment 8818962 [details]
Bug 1322455 - When cloning an <input>, avoid re-initializing checkedness in DoneCreatingElement. .

https://reviewboard.mozilla.org/r/98866/#review99160

Following various flags in HTMLInputElement has become rather hard. I wonder how to improve that. Oh well, not about this bug.
Attachment #8818962 - Flags: review?(bugs) → review+
Pushed by hsivonen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5bb140e08339
When cloning an <input>, avoid re-initializing checkedness in DoneCreatingElement. r=smaug.
https://hg.mozilla.org/mozilla-central/rev/5bb140e08339
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Comment on attachment 8818962 [details]
Bug 1322455 - When cloning an <input>, avoid re-initializing checkedness in DoneCreatingElement. .

Approval Request Comment
> [Feature/Bug causing the regression]:

Bug 1310865.

> [User impact if declined]:

Pages that clone forms with checkboxes or radiobuttons may misbehave by getting the checkedness state wrong.

> [Is this code covered by automated tests?]:

Yes.

> [Has the fix been verified in Nightly?]:

Yes.

> [Needs manual test from QE? If yes, steps to reproduce]: 

No need, but the steps are:
 1) Load https://hsivonen.com/test/moz/clone-checked.html
 2) Check the first box.
 3) Uncheck the second box.
 4) Click the button.
 5) Ensure the third box is checked.
 6) Ensure the fourth box is unchecked.

> [List of other uplifts needed for the feature/fix]:

None.

> [Is the change risky?]:

Relatively unrisky.

> [Why is the change risky/not risky?]:

The patch flips one boolean which is checked in only one place, so the impact should be very constrained.

> [String changes made/needed]:

None.
Attachment #8818962 - Flags: approval-mozilla-beta?
Attachment #8818962 - Flags: approval-mozilla-aurora?
Hi :emilpasca,
Could you help verify if this issue is fixed as expected on the latest Nightly build? Thanks!
Flags: needinfo?(emil.pasca)
Flags: qe-verify+
Comment on attachment 8818962 [details]
Bug 1322455 - When cloning an <input>, avoid re-initializing checkedness in DoneCreatingElement. .

Fix a regression. Beta51+ and Aurora52+. Should be in 51 beta 9.
Attachment #8818962 - Flags: approval-mozilla-beta?
Attachment #8818962 - Flags: approval-mozilla-beta+
Attachment #8818962 - Flags: approval-mozilla-aurora?
Attachment #8818962 - Flags: approval-mozilla-aurora+
needs rebasing for beta
Flags: needinfo?(hsivonen)
Flags: needinfo?(hsivonen)
I managed to reproduce the issue on 53.0a1 (2016-12-07). The bug is verified fixed on latest Nightly 53.0a1 (2016-12-28), latest Aurora 52.0a2 (2016-12-29) and on 51.0b10 (20161222080852), using Windows 10 x64, Ubuntu 14.04 x86 and Mac OS X 10.11.6.
Flags: needinfo?(emil.pasca)
You need to log in before you can comment on or make changes to this bug.