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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev