Right now on master, the thumb of the sliders in the "Sound" and "Display" Settings screens will jump to the max value if the touchend event happens inside the bounds of the <input type=range> element (it will "take" if the touchend occurs outside). This only happens on an actual device and in the emulator. I'm having a lot of trouble debugging this because the JavaScript Debugger does not currently work with an actual device or the emulator (bug 797627 will fix this, I think): https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Debugging/Setting_up#Enabling_debugging_on_a_Firefox_OS_device

printf debugging FTW! This comes down to the Settings app's use of: https://github.com/mozilla-b2g/gaia/blob/master/shared/js/mouse_event_shim.js This "shim" code creates and dispatches synthetic mouse events that shadow real touch events. See handleTouchStart, handleTouchMove and handleTouchEnd. This bug happens as a result of the emitEvent calls in handleTouchEnd, specifically. Synthetic events do not go through the widget paths that real events go through, so the 'widget' member of the nsGUIEvents for the synthetic events sent by the shim code is never set. This causes problems under the stack: nsLayoutUtils::GetEventCoordinatesRelativeTo nsRangeFrame::GetValueAtEventPoint HTMLInputElement::FinishRangeThumbDrag HTMLInputElement::PostHandleEventForRangeThumb because we hit this line: http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp?rev=7b8ed29c6bc0&mark=1252#1241 So for the synthetic events that gaia's mouse_event_shim.js script sends out, we end up calculating the value of the range for a point that has its x and y set to NS_UNCONSTRAINEDSIZE, which is the maximum value that can be stored in an int. Hence why nsRangeFrame::GetValueAtEventPoint ends up setting the range to its max value.

It seems to me that the shim code should not dispatch synthetic events to native form controls, since they should be fully touch event aware and not need them. Unfortunately, from previous conversations with djf in #gaia (10 days ago), he was extremely reluctant to be making any changes to mouse_event_shim.js since it's apparently a very fragile hack.

Actually the WIP touch events spec[1] seems rather ill-defined. It basically says UAs may choose to dispatch touch events with or without mouse events (so leaves it undefined and up to implementers to do what they want). It's also very unclear what conditions might limit which events are dispatched (e.g. whether certain events are a "consequential result" of other events or not seems to be left up to the imagination of the reader). From my conversations with various people there seems to be disagreement over whether mouse events should be sent with touch events, whether preventDefaulting certain touch events should prevent the related mouse events from being dispatched, etc. It doesn't look like this will be agreed or spec'ed properly any time soon, so it's not really clear if or how the mouse_event_shim.js code should change. Really this script needs to go away in favor of internal gecko dispatched events once the spec is sorted out, but that's some way off. 1. https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html

For now I've pushed a check for the error condition that is causing this bug in order to prevent this issue causing people problems while we work out the more fundamental issues: https://hg.mozilla.org/integration/mozilla-inbound/rev/1a418f831f2c

I filled bug 861737 and bug 861735 for some of the larger issues here, although I wouldn't hold by breath on seeing those fixed any time soon.