[webkit-dev] HitTest'ing scrollbars

Mon May 3 12:40:41 PDT 2010

Hi.

While working on bug 16809 (Clicking a scrollbar blurs the currently
focused element), a couple of questions raised about the current
behavior of mouse clicks on scrollbars.

On ports that do *not* use platform/native widgets for rendering
scrollbars (including Qt, Windows, Chromium):

1) clicking on a frame scrollbar will hitTest WebCore at the position
of this main frame scrollbar but won't set HitTest::scrollbar, while
hitTest'ing an in-frame scrollbar (e.g. a scrollbar of a scrollbable
div) does set it. Is this behavior by design?

Due to that, snippets like the following are needed in certain cases:

EventHandler::handleMousePressEvent(PlatformMouseEvent&)
{
(...)
  FrameView* view = m_frame->view();
        Scrollbar* scrollbar = view ?
view->scrollbarAtPoint(mouseEvent.pos()) : 0;
        if (!scrollbar)
            scrollbar = mev.scrollbar();
(...)
}

It seems strange that we have to rely on scrollbarAtPoint of FrameView
and fallback to HitTest::scrollbar . Maybe the former should not be
necessary if HitTest::scrollbar got set properly.

2) Clicking on main frame scrollbars will set <HTML> as
HitTest::targetNode . This seems like an intentional behavior
according to the comment in the snippet below:

bool RenderLayer::hitTest(const HitTestRequest& request, HitTestResult& result)
{
(...)
  RenderLayer* insideLayer = hitTestLayer(this, 0, request, result, boundsRect,
result.point(), false);
  if (!insideLayer) {
    // We didn't hit any layer. If we are the root
    // layer and the mouse is -- or just was -- down,
    // return ourselves. We do this so mouse events
    // continue getting delivered after a drag has
    // exited the WebView, and so hit testing over
    // a scrollbar hits the content document.
    if ((request.active() || request.mouseUp()) && renderer()->isRenderView())
   {
      renderer()->updateHitTestResult(result, result.point());
      insideLayer = this;
   }
}
(...)

But due to that, some "side effects" like [1] shows up. I would like
to confirm if this is also an intentional behavior before marking bugs
as INVALID or WONTFIX.

3) HitTest'ing a frame scrollbar bar will dispatch, MouseDown event,
but not MousePress and MouseUp. It seems different from what other
vendors do currently (run this testcase in various browsers [2],
including not webkit based ones). Why this behaviour?

[1] https://bugs.webkit.org/show_bug.cgi?id=29484 ("[Qt] Clicking on
the frame's scrollbar trigger a click event in the page.")
[2] https://bugs.webkit.org/attachment.cgi?id=20748

-- 
--Antonio Gomes