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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 11 15:39:33 PDT 2009


--- Comment #30 from Viet-Trung Luu <viettrungluu at gmail.com>  2009-08-11 15:39:28 PDT ---
(In reply to comment #29)
> Sorry for confusing you with the earlier person working on this bug!

No worries. :-)

> If that’s true, then perhaps we should name it for when it should be called
> rather than for what it does. Maybe contentMovedUnderMouse() or something along
> those lines?

That sounds like a good name.

> Seems like a reasonable first step. Lets not set our sights too low though.
> Lets try to fix this all the way!

So an issue is that, as I said, the PlatformMouseEvent's go fairly deep. In
particular, we need to tell our Scrollbar's that the mouse position has changed
relative to them. (This isn't true for the window scrollbars for the scrolling
case, but is needed for a resize; for example, if the resize causes the mouse
to be over or to leave the scrollbar, it may need to update its hover state.)
Now, the stuff in Scrollbar.cpp isn't a problem, but it calls down to
ScrollbarTheme ... which involves code in many places. There's also the mouse
event dispatch code (going down into the DOM code), though that looks more
easily manageable.

Possible solutions:
(1) Refactor everything, ditching PlatformMouseEvent's where possible. (Seems a
bit like overkill? This would affect code in many places, including platform
(2) Add methods which don't require PlatformMouseEvent's alongside the current
ones. (Adds either hard-to-maintain redundancy -- or complexity, if code is
refactored to make things common. Not really any better than (1), since it
would also touch platform code.)
(3) Add an event type to PlatformMouseEvent -- "MouseEventUpdatePosition" or
some such; code which cares can look for it. (Possible bugs in code which
assumes all data are valid, but that would happen with fake mouse moves
(4) Generate fake PlatformMouseEvent's (with a fake MouseEventMoved). Obviously
"works", but it's a pack of lies.

I'm kind of inclined towards (3). For things like keyboard flags, one could
similarly have "MouseEventUpdateKeys".

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

More information about the webkit-unassigned mailing list