Closed
Bug 939396
Opened 9 years ago
Closed 9 years ago
onChange event is not fired on input type range for first time
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: tasleem.fahad, Assigned: jwatt)
References
()
Details
(4 keywords, Whiteboard: [bugday-20131118][qa-])
Attachments
(1 file)
3.47 KB,
patch
|
smaug
:
review+
bajaj
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20131025151332 Steps to reproduce: 1. Attach an onChange handler on input type range 2. Change the value by clicking (not by dragging) 3. The handler is not called as the event is not fired. 4. Change the value again (second time) 5. The event gets fired and handler is executed. Actual results: onChange is not fired for first time Expected results: OnChange should be fired
![]() |
||
Comment 1•9 years ago
|
||
Is it bug 890710? If not, please attach a testcase. [The Priority part of the Importance field is for the developers only.]
It is different, I think. I have attached the fiddle URL (http://jsfiddle.net/3g9F3/).
![]() |
||
Comment 3•9 years ago
|
||
Thanks. It has always been so, since bug 851090 was fixed. no event: 2013-03-17-03-09-23-mozilla-central-firefox-22.0a1.en-US.linux-x86_64 bug: 2013-03-18-03-09-47-mozilla-central-firefox-22.0a1.en-US.linux-x86_64
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
Version: 25 Branch → Trunk
Comment 5•9 years ago
|
||
jwatt might be interested in this stuff.
![]() |
Assignee | |
Comment 6•9 years ago
|
||
I implemented <input type=range>, but I don't anticipate getting to this in the few weeks before I go off on PTO.
Jwatt maybe?
Flags: needinfo?(jonas) → needinfo?(jwatt)
![]() |
Assignee | |
Updated•9 years ago
|
Flags: needinfo?(jwatt)
Comment 8•9 years ago
|
||
Would this be something you could act as a mentor for, in that case?
Flags: needinfo?(jwatt)
![]() |
Assignee | |
Comment 9•9 years ago
|
||
sure
Flags: needinfo?(jwatt)
Whiteboard: [bugday-20131118] → [bugday-20131118][mentor=jwatt][lang=c++]
![]() |
Assignee | |
Comment 10•9 years ago
|
||
The reason this is happening is because the code to handle 'focus' events resets the mFocusedValue member, but this happens after the 'click' event has triggered a StartRangeThumbDrag() call that updates the value (and range thumb position). Hence the focus code is unwittingly overwriting mFocusedValue with the value that the range got due to the click, and not leaving it with the value it had just before the click.
Whiteboard: [bugday-20131118][mentor=jwatt][lang=c++] → [bugday-20131118]
![]() |
Assignee | |
Comment 11•9 years ago
|
||
Assignee: nobody → jwatt
Attachment #8335622 -
Flags: review?(bugs)
![]() |
Assignee | |
Updated•9 years ago
|
tracking-firefox26:
--- → ?
tracking-firefox27:
--- → ?
Comment 12•9 years ago
|
||
Am I reading correctly that this has been the case since bug 851090 landed in FF22? If that's the case and we haven't seen a ton of web breakage because of this, there's no reason to hold a release for this fix. Please nominate for uplift if low risk and we'll go as high as we can at that time but it's quite late in the FF26 beta cycle and we're throttling down on taking speculative fixes at this point so unless there's something I'm not seeing here in terms of urgency this might only get as high as FF27.
status-firefox26:
--- → affected
status-firefox27:
--- → affected
status-firefox28:
--- → affected
tracking-firefox27:
? → ---
Flags: needinfo?(jwatt)
Keywords: regression
![]() |
Assignee | |
Comment 13•9 years ago
|
||
Okay. I don't think this is super high priority, but it does seem a bit bad that script won't get notified of changes caused by a click. I'll nominate after review.
Flags: needinfo?(jwatt)
Updated•9 years ago
|
Attachment #8335622 -
Flags: review?(bugs) → review+
![]() |
Assignee | |
Comment 14•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/5c370cd2f75a
Comment 15•9 years ago
|
||
Nominate for uplift when ready and we'll see how high up we can lift it safely.
Comment 16•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/5c370cd2f75a
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
![]() |
Assignee | |
Comment 17•9 years ago
|
||
Comment on attachment 8335622 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 344618 User impact if declined: script isn't notified of click changes to ranges Testing completed (on m-c, etc.): been on m-c for a week or so Risk to taking this patch (and alternatives if risky): pretty low String or IDL/UUID changes made by this patch: none Probably not for beta at this point, but I think we should definitely take it on aurora.
Attachment #8335622 -
Flags: approval-mozilla-aurora?
Updated•9 years ago
|
Attachment #8335622 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
![]() |
Assignee | |
Updated•9 years ago
|
Keywords: checkin-needed
Whiteboard: [bugday-20131118] → [bugday-20131118][needs landing on aurora]
Comment 18•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/0d728d9700df
Keywords: checkin-needed
Whiteboard: [bugday-20131118][needs landing on aurora] → [bugday-20131118]
Updated•9 years ago
|
Keywords: site-compat
Comment 19•9 years ago
|
||
I don't think this needs QA verification. If anyone thinks that's a mistake please remove the [qa-] whiteboard tag and add the verifyme keyword.
Whiteboard: [bugday-20131118] → [bugday-20131118][qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•