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

Issue 534245 link

Starred by 11 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

<input> of type=checkbox,radio,file doesn't fire `input` events

Reported by cvreb...@gmail.com, Sep 21 2015

Issue description

Chrome Version       : 45.0.2454.93
OS Version: OS X 10.10.5
URLs (if applicable) : http://jsbin.com/jojoji/edit?html,output
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36

Per the following portions of the HTML specification:
* https://html.spec.whatwg.org/multipage/forms.html#checkbox-state-(type=checkbox):event-input-input
* https://html.spec.whatwg.org/multipage/forms.html#radio-button-state-(type=radio):event-input-input
* https://html.spec.whatwg.org/multipage/forms.html#file-upload-state-(type=file):event-input-input

when the user changes the checkedness of an <input type="checkbox"> or <input type="radio">, or when a user changes the selected files of an <input type="file">, the browser is supposed to fire an `input` event (https://developer.mozilla.org/en-US/docs/Web/Events/input ) at that <input> element.
Chrome doesn't currently comply with this, and doesn't fire `input` events in these cases.

What steps will reproduce the problem?
1. Open http://jsbin.com/jojoji/edit?html,output in Chrome.
2. Check the checkbox.
3. Click one of the two radio buttons.
4. Click "Choose File" and select a file.

What is the expected result?
After each of steps 2 thru 4, an alert box with the message "input!" should be displayed (because an `input` event should be fired at the respective <input> element).

What happens instead of that?
No alert boxes are shown because no `input` events were fired.

 
Labels: Cr-Blink-Forms Needs-Feedback
Thanks for the report. I am observing the similar behavior across browsers Firefox 39, Safari 8 & IE11, no alert is displayed after steps 2. Request you to please confirm the same.


I really appreciate your help

Thank you!

Comment 2 by tkent@chromium.org, Sep 21 2015

Labels: -Pri-2 Pri-4
Status: Available

Comment 3 by cvreb...@gmail.com, Sep 21 2015

> Thanks for the report. I am observing the similar behavior across browsers
> Firefox 39, Safari 8 & IE11, no alert is displayed after steps 2. Request you
> to please confirm the same.

Yes, the other browsers don't seem to correctly implement this yet either. I am lodging bugs against them as well.

Comment 4 by cvreb...@gmail.com, Sep 28 2015

ashej@ Please acknowledge that feedback has been given. Thanks.

Comment 5 by tkent@chromium.org, Sep 28 2015

Labels: -OS-Mac -Needs-Feedback OS-All

Comment 6 by tkent@chromium.org, Oct 4 2015

 Issue 538806  has been merged into this issue.

Comment 8 by tkent@chromium.org, Feb 10 2016

Status: ExternalDependency

Comment 9 by zcorpan@gmail.com, Feb 16 2016

Cc: chongz@chromium.org dtapu...@chromium.org
Status: Available
Chong, Dave, you're working on InputEvent which is related; are you interested in fixing this?
Cc: tkent@chromium.org
Components: Blink>Input
Labels: -Pri-4 Hotlist-Input-Dev Pri-2
Including this with chong's work on the `input` event is fine with me (it's probably easy and low risk to change). But it could also belong to the DOM team since they own forms (/cc tkent).

Comment 11 by tkent@chromium.org, Feb 26 2016

Actually, I'm negative of adding new 'input' events, and I don't want to add new 'input' events until other browsers implement them.

All browsers dispatch 'change' and 'input' events synchronously, and these new 'input' events need to be synchronous too.  As you know, synchronous events have made a lot of bugs.

I'd be happy if 'input' and 'change' evens are dispatched asynchronously for these input types.

Firefox 49 now fires these events: https://bugzilla.mozilla.org/show_bug.cgi?id=1206616
 Issue 799461  has been merged into this issue.
Owner: shanmug...@samsung.com
Status: Assigned (was: Available)
Project Member

Comment 16 by bugdroid1@chromium.org, Jan 19 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54f8d098b694704893f7abdbba3b1a6ee18ed687

commit 54f8d098b694704893f7abdbba3b1a6ee18ed687
Author: Shanmuga Pandi M <shanmuga.m@samsung.com>
Date: Fri Jan 19 06:26:58 2018

Emit "input" event on activation behavior for CheckBox

Intent to implement and ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Qc-bOSyU0FQ

Bug:  534245 
Change-Id: Ib97235c26b4b3ccd681e708e232a782d5612745c
Reviewed-on: https://chromium-review.googlesource.com/861601
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Shanmuga Pandi <shanmuga.m@samsung.com>
Cr-Commit-Position: refs/heads/master@{#530435}
[delete] https://crrev.com/32c5f6b31c49bb0673bdc0cb0e464765d6ca82a1/third_party/WebKit/LayoutTests/external/wpt/html/semantics/forms/the-input-element/checkbox-click-events-expected.txt
[delete] https://crrev.com/32c5f6b31c49bb0673bdc0cb0e464765d6ca82a1/third_party/WebKit/LayoutTests/external/wpt/html/semantics/forms/the-input-element/checkbox-expected.txt
[add] https://crrev.com/54f8d098b694704893f7abdbba3b1a6ee18ed687/third_party/WebKit/LayoutTests/fast/forms/checkbox/checkbox-keyboard-event.html
[modify] https://crrev.com/54f8d098b694704893f7abdbba3b1a6ee18ed687/third_party/WebKit/Source/core/html/forms/CheckboxInputType.cpp
[modify] https://crrev.com/54f8d098b694704893f7abdbba3b1a6ee18ed687/third_party/WebKit/Source/core/html/forms/HTMLInputElement.cpp
[modify] https://crrev.com/54f8d098b694704893f7abdbba3b1a6ee18ed687/third_party/WebKit/Source/core/html/forms/HTMLInputElement.h

Project Member

Comment 17 by bugdroid1@chromium.org, Jan 30 2018

Comment 18 by tkent@chromium.org, Jan 30 2018

Labels: M-66
Status: Fixed (was: Assigned)

Sign in to add a comment