Bug 18652 - onchange events don't seem to fire for input[type=range] controls.
Summary: onchange events don't seem to fire for input[type=range] controls.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://www.ipsilonconsulting.co.uk/bu...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-21 02:55 PDT by Greg Harewood
Modified: 2008-05-03 23:39 PDT (History)
0 users

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Harewood 2008-04-21 02:55:53 PDT
onchange events don't seem to fire for input[type=range] controls.
Comment 1 Rob Buis 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.
Comment 2 Maciej Stachowiak 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.
Comment 3 Maciej Stachowiak 2008-04-26 13:33:47 PDT
The test should probably check that "change" is sent after "input".
Comment 4 Rob Buis 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.
Comment 5 Rob Buis 2008-04-27 23:54:09 PDT
Landed in r32610.
Comment 6 Greg Harewood 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.)
Comment 7 Rob Buis 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.
Comment 8 Rob Buis 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.
Comment 9 Rob Buis 2008-05-03 23:39:58 PDT
Landed in r32849.