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

Tue Aug 11 12:29:13 PDT 2009

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

--- Comment #28 from Viet-Trung Luu <viettrungluu at gmail.com>  2009-08-11 12:29:09 PDT ---
[Just for clarity, I'm not the originator of the original patch....]

(In reply to comment #27)
>     a) How we detect that there's a change that requires some mouse position
> processing.

I guess there are two approaches to this (and intermediates between the two
extremes):
(i) Code which does anything which causes changes which require such processing
initiate the processing. Advantages: efficient (no extra checking needed).
Disadvantages: need to carefully wire up lots of code.
(ii) Check whether such processing is needed very often (possibly prompted by
code which does anything which remotely *may* cause such a need), and do the
processing if necessary. Advantages: no need to wire up other code so
carefully. Disadvantages: nontrivial processing and possibly inefficient.

In my quick-and-dirty patch, I've taken route (i):
EventHandler::mouseMovedVirtually() is a stub which tells the EventHandler that
something happened which caused the mouse to move "virtually". Currently, this
immediately fires off a fake mouse event (ugh), but upon decoupling the code it
could do something better; it could also be set to start a timer (to coalesce),
etc.

>     b) What should be seen at the DOM level. [...]

Right. I (as opposed to the original patch's author) wired up a fake mouse move
purely out of expediency -- it's clearly not right. It forces a policy decision
(send mouse move events on "virtual" mouse moves), but we shouldn't let a hack
make policy. That said, sending a DOM mouse move may be desired, after all.

> What do we want seen at the DOM level when the option key goes down? Probably
> not a "mouse move" event, so that's a minor bug on the Mac that would be nice
> to fix. Unless we decide it's a feature rather than a bug.

Seems unlikely that that's a feature! I wouldn't want the option key to be
hooked up to virtual mouse moves either, so that processing should probably be
separated.

> It may be expedient to use what looks like a "mousemove" event to minimize
> refactoring of the existing code. But I think that sort of lack of clarity and
> logic in the code is unnecessary. We should be willing to make some changes to
> make this logical unless it's so difficult that it makes the problem a lot
> harder to fix.

It's a little painful since we have ugly scrollbar, etc. code which would also
need to be rewired, the details which are a bit painful to get right.
Currently, a lot of code is wired up to take a PlatformMouseEvent, probably
unnecessarily.

> It would be very useful to determine where those events come from. Is it the
> Mac OS X AppKit that is providing these events? Or is it the Mac-specific
> WebKit code that creates them? If the former, then we should just live with
> them as is. If it's the latter, maybe we can solve this in a platform
> independent way and get rid of the unneeded code.

I wouldn't want to bet my life on it, but I would guess the former, or actually
code in Safari itself. I don't think I've seen code that does this in WebKit
(and Chromium/Mac doesn't get extra events).

> > When
> > scrolling using the keyboard, in Safari/Mac, the cursor (and tooltip)
> > disappear, thereby eliminating a bunch of problems; [...]
> 
> This is an interesting point. It hides some problems (cursor and tooltip) but
> doesn't affect others at all (status bar, DOM events as seen on the web page,
> hover effects in the page).

True, and of course it doesn't help with scrolling with
trackpad/mousewheel/other either.

> Why don't other platforms have this behavior? Is this really a unique feature
> of Mac OS X, or is this something we'd want on Windows and Unix desktop systems
> too?

It's standard on Mac, doesn't happen on Windows (in any browser that I know of,
at least). I don't know about Unix desktops....

> I don't think this refactoring and clean-up is particularly difficult, and I'd
> love to see it done for code clarity either before or after this bug is fixed.
> I agree that it doesn't have to be done to fix the bug.

Agreed, which is why my (even quick-and-dirty) patch is written as it is. For
the mouse-related stuff (I don't know about the option key, etc.), I would
separate out the code in mouseMoved() and handleMouseMoveEvent(), and have them
(and mouseMovedVirtually()) call down to the common code appropriately.

> This seems to cover only a tiny fraction of problem (a). It's true that a
> FrameView scrolling can move an element. But also, changes to the element's
> geometry can move it. And overflow area scrolling can also move it. I'd like to
> understand our general strategy to detecting when elements move out from under
> the mouse. It may be that once we cover the general case we don't need anything
> separate for FrameView.

I suppose that, adopting my tactic (i), we'd have to wire up all these other
things explicitly as well. Our "general strategy for detecting when elements
move out from under the mouse" rests right now entirely in EventHandler (not so
great, but everything else seems mostly unaware of the mouse!), and in
handleMouseMoveEvent() in particular (at least that should be changed).

A further possible issue is that we may need to know whenever the mouse moves
relative to anything (leaving an element); this would be the case if we want to
send DOM mouse moves when scrolling, for example.

> My main complaint about your initial patch was that making a fake mouse event
> in response to a real wheel event is wrong. The major way it's wrong is (a).
> It's wrong to say that a wheel event is causing this. It's the *response* to
> the wheel event that creates the need to update things like cursors and makes
> you want to send a simulated mouse move event.

[Not my original patch, which is why I wired up to the scrolling instead....]

So what do you think of having a separate mouseMovedVirtually() method in
EventHandler? As I said, it and mouseMoved()/etc. should be refactored, but the
semantics of mouseMovedVirtually() are quite clear -- whenever the mouse moves
relative to any elements (without the mouse actually moving -- i.e., the
elements move!), it should be called. Currently, I call it from the scrolling
code, but it should be called from elsewhere as well; it may need to be made
more sophisticated to work correctly in those cases, but it's a start.

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