This API call needs to be public in order to be able to implement frames or blocks with an overflow in a browser application.
fwiw, in bug 39217 I introduced an additional 'starting node' parameter to EventHandler::scrollRecursively and scrollOverflow that can/should be used in the body implementation of this method.
It turned out to be useful to the WRT guys as well.
related bugs: 1) https://bugs.webkit.org/show_bug.cgi?id=32668 2) https://bugs.webkit.org/show_bug.cgi?id=36674 3) https://bugs.webkit.org/show_bug.cgi?id=35873
Thinking about it, two behaviors are possible regarding to the scroll distance. Let's say we scroll 100px on a div with overflow, where the scroll span left is 40px: 1) scroll 40px and ignore the 60px left from the call 2) scroll 40px on the div, and then 60px on the parent frame In my opinion, (1) is the correct for touch inteface with inner scrolling. I can see (2) being useful when scrolling programatically. I lower the priority of this task since there are more urgent thing to do and Joseph does not seem to follow up on this problem.
(In reply to comment #4) > Thinking about it, two behaviors are possible regarding to the scroll distance. > > Let's say we scroll 100px on a div with overflow, where the scroll span left is 40px: > 1) scroll 40px and ignore the 60px left from the call > 2) scroll 40px on the div, and then 60px on the parent frame > > In my opinion, (1) is the correct for touch inteface with inner scrolling. I can see (2) being useful when scrolling programatically. > > I lower the priority of this task since there are more urgent thing to do and Joseph does not seem to follow up on this problem. From my experience with Spatial Navigation, I agree with you, Bengamin. (1) Seem to be a better approach, because with (2), we sometime get premature scrolling of the parent container. Joe left Nokia, so I doubt that he will continue working on this bug :-)
WONTFIX, likely