New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 773680 link

Starred by 2 users
Status: Available
Owner: ----
Cc:
█ paritosh...@samsung.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

MouseEvent('click') on input[radio/checkbox] does not fire "change" event when input is not attached to body

Reported by mjsta...@gmail.com, Oct 11 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0

Steps to reproduce the problem:
1. Create an input element of type radio with DOM APIs
2. attach eventListener "change" to radio
3. dispatch MouseEvent('click)on radio

See http://embed.plnkr.co/YyVkQb2U80yytr7zwWJm/ for demo

What is the expected behavior?
the eventListener "change" on the radio is called

What went wrong?
The eventListener is not called.

Did this work before? N/A 

Chrome version: 61.0.3163.100  Channel: n/a
OS Version: 10.0
Flash Version: 

I don't know if anything is in the spec that handles this behavior. The relevant part about events I found here: https://html.spec.whatwg.org/multipage/input.html#radio-button-state-(type=radio)

Firefox / IE / Edge fire the "change" event correctly, Safari does not. So this possibly goes back to Webkit.

Comment 1 by dtapu...@chromium.org, Oct 11 2017

Cc: hayato@chromium.org
Components: -Blink Blink>Forms
Seems this check for connectedness to dispatch the change event was added in https://chromium.googlesource.com/chromium/src/+/6329eb6791ef66c8a9b00037873f1a969d00cc35

Whether it is standards compliant I don't know. The HTML forms team should likely add a WPT test and determine if this should be changed. 

I agree it is odd to base the change event on connectedness.

Comment 2 by ligim...@chromium.org, Oct 11 2017

Labels: Needs-Triage-M61

Comment 3 by tkent@chromium.org, Oct 12 2017

Cc: -hayato@chromium.org paritosh...@samsung.com
Components: -Blink>Forms Blink>Forms>Checkbox
Labels: -Type-Bug -Arch-x86_64 -Via-Wizard-Javascript -Needs-Triage-M61 Hotlist-Interop OS-Android OS-Chrome OS-Linux OS-Mac Type-Bug-Regression
Status: Available (was: Unconfirmed)
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 12

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by tkent@chromium.org, Oct 15

Components: Blink>Forms>Radio
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
►

Sign in to add a comment