Clean-up hit-testing of scrollbars

Clean-up hit-testing of scrollbars

Today there are three different ways we hit-test for scrollbars:
1) for frame scrollbars, explicitly call FrameView::scrollbarAtPoint
2) for subframe scrollbars, use HitTestRequest::AllowFrameScrollbars
3) for DIV scrollbars, rely just on the normal HitTestResult

There's apparently no good reason not to be consistent here.  This patch
updates hit-testing to always consider all 3 types of scrollbars, and
removes the AllowFrameScrollbars mode entirely.

This also fixes a bug where we weren't properly hit-testing for
subframe scrollbars on tap, and so not sending mouse events through
to the frame behind (as we do for touch).

I also split ScrollView::scrollbarAtPoint into two variants for window
and view co-ordinates (since we weren't being consistent previously,
passing view co-ordinates as if they were window co-ordinates in
RenderPart::nodeAtPoint.

BUG=410661
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=181935

[Rick Byers, 2014-09-11 23:03:08]

rbyers@chromium.org changed reviewers:
+ esprehn@chromium.org

[Rick Byers, 2014-09-11 23:03:09]

Elliott, PTAL

[esprehn, 2014-09-12 20:50:29]

lgtm, we really need to stop taking Point objects entirely and introduce
something like a WindowPoint and a ViewPoint object and force callers to be
explicit about which one they want. There's a lot of bugs in the system where we
use the wrong coordinate space. (I know that's a huge project, not suggesting
you do it, just thinking out loud...)

[Rick Byers, 2014-09-12 21:21:26]

On 2014/09/12 20:50:29, esprehn wrote:
> lgtm, we really need to stop taking Point objects entirely and introduce
> something like a WindowPoint and a ViewPoint object and force callers to be
> explicit about which one they want. There's a lot of bugs in the system where
we
> use the wrong coordinate space. (I know that's a huge project, not suggesting
> you do it, just thinking out loud...)

Thanks!  Yeah, I've long fantasized about a nice templated type system that
would even include WHICH layer/window a point was relative to etc.  I wonder if
there's a practical way we could start chipping away at this problem without
having boil-the-ocean problems (eg. with some handy temporary implicit
conversions back to raw data types).  Anyway, as you say, not for this CL...

[Rick Byers, 2014-09-12 21:21:32]

The CQ bit was checked by rbyers@chromium.org

[commit-bot: I haz the power, 2014-09-12 21:22:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/527263002/60001

[commit-bot: I haz the power, 2014-09-12 21:33:23]

Committed patchset #4 (id:60001) as 181935