[Webkit-unassigned] [Bug 17052] Scrolling with arrow keys does not update cursor

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=17052


Viet-Trung Luu <viettrungluu at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |viettrungluu at gmail.com




--- Comment #25 from Viet-Trung Luu <viettrungluu at gmail.com>  2009-08-10 21:08:56 PDT ---
Darin,

Safari/Mac appears to generate extra mouse move events for lots of things
(including, e.g., mouse downs/ups), thereby avoiding a host of bugs. When
scrolling using the keyboard, in Safari/Mac, the cursor (and tooltip)
disappear, thereby eliminating a bunch of problems; actually, now that
Chromium/Mac also makes the cursor (and consequently the tooltip, apparently)
disappear, those same problems go away.

Now, unfortunately, the mouse moving code
(EventHandler::mouseMoved()/handleMouseMoveEvent()) are very tightly coupled
with PlatformMouseEvent. To handle "virtual mouse moves", we need to at least
do either (1) send fake mouse move events (ugly, but expedient) or (2) decouple
the aforementioned code so that it can handle such "virtual mouse moves"
without a PlatformMouseEvent (make an "EventHandler::mouseMovedVirtually()"
method or some such). In some sense, the difference between (1) and (2) is
cosmetic. You could decouple so far as to push a lot of the logic down into the
layout, but that would be drastic and you'd have to make the layout aware of
the mouse position.

My first instinct to fix the scrolling-related issues is to hook up (1) or (2)
in FrameView::valueChanged() (probably inside the "if (offset !=
scrollOffset())"). Similarly, you could do the same in
FrameView::performPostLayoutTasks() -- I think this would probably handle any
possible resize-related issues. (There are also possible window-movement issues
-- i.e., the window moves without the mouse moving -- though I don't know
offhand where that would get hooked up.)

Hooking up a fake mouse event is expedient, if a little repugnant; decoupling
the code is a bit fragile and goes pretty deep. (E.g., on resize, the mouse may
end up over a scrollbar, so you can't just ignore the scrollbars.)

Maybe I'll come up with a patch which sends a fake mouse event, and see if it
works.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.