BlackBerry port need to set the event default handled for those send to SliderThumbElement, so that when the user slides it to change the range associated with it, the event will be consumed to prevent zooming or scrolling.
Created attachment 138301 [details] Patch
Comment on attachment 138301 [details] Patch Could do a test to m? go to Source/WebCore/dom/MouseEvent.cpp , and comment out the blackberry specific code. rebuild and please check if input sliders can still get dragged without scrolling the webpage.
(In reply to comment #2) > (From update of attachment 138301 [details]) > Could do a test to m? > > go to Source/WebCore/dom/MouseEvent.cpp , and comment out the blackberry specific code. rebuild and please check if input sliders can still get dragged without scrolling the webpage. As my test result shows and the discussion offline, this has nothing to do with this patch.
Comment on attachment 138301 [details] Patch I will check with the original guy/commit who "regressed" this, and see with if we can do this code cross platform. If so, I will take my r- back and advice the way to go.
This was the commit that removed the setDefaultHandled call in case of mousemove events: commit d81223d29e6fe8fece485860533c0860185c26cc Author: tkent@chromium.org <tkent@chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc> Date: Wed Jul 20 04:46:35 2011 +0000 REGRESSION(r89004): Video pauses and never resumes playing if scrubbed during playback. https://bugs.webkit.org/show_bug.cgi?id=64314 Reviewed by Sam Weinig. No new tests because it's hard to make a non-flaky test for this behavior. * html/RangeInputType.cpp: (WebCore::RangeInputType::handleMouseDownEvent): Don't call SliderThumbElement::dragFrom() for events on the thumb. * html/shadow/SliderThumbElement.cpp: (WebCore::SliderThumbElement::defaultEventHandler): Do not call setDefaultHandled() for mouse events in order to propagate them to ancestor elements. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@91333 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Pasting original comments from bug 64314 here: In reply to comment #26) > Committed r91333: <http://trac.webkit.org/changeset/91333> Kent, is this the right thing to do for "input type=range" case? Now, no events get set as handled at all in case of range input. More specially, getting the mouse-move set as 'defaultHandled' when dragging the slider is specially useful for touch-based input devices, if they want to make this slider draggable. @Kent, as you asked long ago, here are some more details: in the BlackBerry port, we want to be able to drag the "knob" of an <input type=range> element instead of scrolling the webpage. For that, it is important that we have the event set as "default handled" properly, so no webpage scrolling takes place. Would you think the #if blackberry approach in the proposed patch is ok? From what I understood, you explicitly removed the setDefaultHandled calls so that the event could bubble up and ancestor elements could handle it. Does it apply for media elements only, or general "input type=range" cases?
(In reply to comment #6) > Pasting original comments from bug 64314 here: > > In reply to comment #26) > > Committed r91333: <http://trac.webkit.org/changeset/91333> > > Kent, is this the right thing to do for "input type=range" case? Now, no events get set as handled at all in case of range input. I think my r91333 should be unnecessary. The media player should listen 'change' events from its shadow sliders. It seems we can pass a C++ callback to EventTarget::addEventListener() as CPPEventListenerType.
WONTFIX. The solution is going to be in PR #176014 (Enable TOUCH_SLIDER)