Side navigation
#8169 closed bug (invalid)
Opened February 03, 2011 06:59PM UTC
Closed February 18, 2011 07:54AM UTC
Last modified March 24, 2012 03:36AM UTC
Change does not fire on input[type=number] on Chrome
| Reported by: | mikhuang@gmail.com | Owned by: | mikhuang@gmail.com |
|---|---|---|---|
| Priority: | high | Milestone: | 1.next |
| Component: | event | Version: | 1.4.3 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
To reproduce on Chrome OSX 8.0.522.237:
<input type="number">
<script>
$('[type=number]').change(function(){
alert(this.value);
})
</script>
Then try scrolling
Attachments (0)
Change History (11)
Changed February 03, 2011 07:12PM UTC by comment:1
| resolution: | → duplicate |
|---|---|
| status: | new → closed |
Changed February 03, 2011 07:12PM UTC by comment:3
| component: | unfiled → event |
|---|---|
| priority: | undecided → high |
| version: | 1.4.4 → 1.4.3 |
Changed February 03, 2011 08:13PM UTC by comment:4
Why is this a duplicate of #8148? There is nothing which indicates a call to .focus() is involved.
Please submit a reduced test case, which reproduces the issue you are experiencing, on http://jsfiddle.net. So that we can investigate this issue further. Also make sure to read the link given below, in order to provide a most useful bug report.
Changed February 03, 2011 09:59PM UTC by comment:5
| resolution: | duplicate |
|---|---|
| status: | closed → reopened |
Changed February 03, 2011 09:59PM UTC by comment:6
| status: | reopened → open |
|---|
Changed February 04, 2011 01:44AM UTC by comment:7
| owner: | → mikhuang@gmail.com |
|---|---|
| status: | open → pending |
As stated above, please provide a reduced test case and more information what you think is wrong / what expected behavior is and how this is jQuery's fault.
This quick stab at making a test case for this (note it doesn't use jQuery) shows that Chrome fires the change event only when the input loses focus and the value has changed. This is afaik also adhering to the HTML 5 specification.
Changed February 18, 2011 07:54AM UTC by comment:8
| resolution: | → invalid |
|---|---|
| status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Changed October 26, 2011 07:41PM UTC by comment:9
Have the same issue. Can replicate the error on URL submitted by jitter http://jsfiddle.net/jitter/q3MEx/.
How may I help?
Changed October 26, 2011 07:47PM UTC by comment:10
That is the correct behaviour for a "change" event. See: http://api.jquery.com/change/
The change event is sent to an element when its value changes. This event is limited to <input> elements, ><textarea> boxes and <select> elements. For select boxes, checkboxes, and radio buttons, the event is fired immediately when the user makes a selection with the mouse, but for the other element types the event is deferred until the element loses focus.
Changed March 24, 2012 03:36AM UTC by comment:11
just a thought pertaining to ops intent of allowing the rolling up and down to trigger some change:
one could bind the "mouseup" event so that the change could be handled.
,
although we would still need the "change" event for direct changes to the input box via keyboard