New issue
Advanced search Search tips

Issue 797154 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Jan 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug



Sign in to add a comment

Using has/get/setAttribute does not work correctly for checked state of input

Reported by bengfarr...@gmail.com, Dec 22 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce the problem:
1. Add a checked state via JS setAttribute('checked', true)
2. Remove the checked state by clicking the checkbox
3. Click the checkbox to "checked" state
4. Try to Remove the checked state via JS removeAttribute('checked')

What is the expected behavior?
In Firefox, set/removeAttribute for checked via JS doesn't appear to work at all. The preferred method of setting .checked works flawlessly anywhere (as it should)

In Chrome's situation, using set/removeAttribute works, but only until the user interacts directly by clicking the input checkbox. Once user interaction occurs, the JS attribute API won't work at all. 

This behavior sets the false expectation that the attribute API will work all the time. 

What went wrong?
Having it working and then not working once user interaction occurs is very confusing

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 63.0.3239.84  Channel: stable
OS Version: 10.0
Flash Version:
test.html
572 bytes View Download

Comment 1 by woxxom@gmail.com, Dec 22 2017 

This is working as per the specification: 
https://html.spec.whatwg.org/multipage/input.html#attr-input-checked

> When the checked content attribute is added, if the control does not have dirty checkedness, the user agent must set the checkedness of the element to true; when the checked content attribute is removed, if the control does not have dirty checkedness, the user agent must set the checkedness of the element to false.

Comment 2 by kochi@chromium.org, Dec 22 2017

Status: WontFix (was: Unconfirmed)
Per comment#1, closing this as WontFix.

Comment 3 by kochi@chromium.org, Dec 22 2017

Components: -Blink>DOM Blink>Forms>Checkbox
Labels: Hotlist-Interop OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac
Status: Untriaged (was: WontFix)
Hmm, maybe worth looking at this in terms of interop with Firefox.

Comment 4 by kochi@chromium.org, Dec 27 2017

Status: Available (was: Untriaged)

Comment 5 by tkent@chromium.org, Jan 9 2018

Status: WontFix (was: Available)
I confirmed Safari TP, and Firefox 58.0a1 have the same behavior with Google Chrome.

Comment 6 by bengfarr...@gmail.com, Jan 9 2018 

Thanks for looking into this. I just tried in FF again, and that behavior is the same (as in I'm seeing the same as tkent). I'm not sure if I was mistaken, or if the version of FF I was using at the time did something different.

Either way, I still feel like it's counter intuitive behavior, but the spec says what it says. I don't necessarily care that it gets fixed, just wanted to prevent similar confusion for someone else.

Thanks again
►

Sign in to add a comment