WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
18652
onchange events don't seem to fire for input[type=range] controls.
https://bugs.webkit.org/show_bug.cgi?id=18652
Summary
onchange events don't seem to fire for input[type=range] controls.
Greg Harewood
Reported
2008-04-21 02:55:53 PDT
onchange events don't seem to fire for input[type=range] controls.
Attachments
First attempt
(3.36 KB, patch)
2008-04-26 09:31 PDT
,
Rob Buis
rwlbuis
: review-
Details
Formatted Diff
Diff
Improved testcase
(3.49 KB, patch)
2008-04-27 00:03 PDT
,
Rob Buis
adele
: review+
Details
Formatted Diff
Diff
Fixing another onchange problem
(3.50 KB, patch)
2008-05-03 13:21 PDT
,
Rob Buis
sam
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Rob Buis
Comment 1
2008-04-26 09:31:49 PDT
Created
attachment 20831
[details]
First attempt Simply fire a changeEvent when dragging the slider. I made sure it is sent after the input event, Opera does the same, my FireFox version does not even have a proper slider... Time to get FF3 I guess :) Cheers, Rob.
Maciej Stachowiak
Comment 2
2008-04-26 13:24:35 PDT
This is what Web Forms 2 says about the "change" event:
> In [DOM3EVENTS] and [HTML4], the change event is fired on a form control element when the control > loses the input focus and its value has been modified since gaining focus.
>
> This specification changes these semantics to more accurately reflect the behaviour expected by Web > authors. Specifically, for controls implemented with a non-editable stateful UI (e.g. select elements, > checkboxes, or radio buttons as deployed in typical desktop Web browsers), the change event shall > be fired when the selection is completed, even if the control does not lose focus. (For example, if a > date control has a button which shows a calendar, then the change event would fire when the > calendar is closed after the user selected a date.)
It's not entirely clear if it means the "change" event to apply even to controls that never take focus at all, but I gues that would make sense and would match checkboxes and radio buttons.
Maciej Stachowiak
Comment 3
2008-04-26 13:33:47 PDT
The test should probably check that "change" is sent after "input".
Rob Buis
Comment 4
2008-04-27 00:03:47 PDT
Created
attachment 20846
[details]
Improved testcase Now we verify input event is sent before change event. Cheers, Rob.
Rob Buis
Comment 5
2008-04-27 23:54:09 PDT
Landed in
r32610
.
Greg Harewood
Comment 6
2008-04-30 04:28:35 PDT
Reopened: The situation of dragging the slider has been resolved, but onchange events are still not fired for clicking the slider directly to a new value. (In fact no events at all are fired, eg onblur also fails to fire.)
Rob Buis
Comment 7
2008-05-03 13:21:37 PDT
Created
attachment 20952
[details]
Fixing another onchange problem This patch fixes the problem that onchange is not fired when clicking (not dragging) the thumb in a position outside of the current thumb position. The extended testcase tests that, and also that clicking within the thumb does not fire an onchange. All this matches Opera, FF3 and IE7 do not have true sliders AFAIK, just line edits with a number for the slider value. Cheers, Rob.
Rob Buis
Comment 8
2008-05-03 23:35:16 PDT
Greg, I think any focus/blur event problems with the slider that you mentioned need a new bug report, preferably with a good testcase. Cheers, Rob.
Rob Buis
Comment 9
2008-05-03 23:39:58 PDT
Landed in
r32849
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug