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

Tue Aug 11 11:13:14 PDT 2009

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

--- Comment #27 from Darin Adler <darin at apple.com>  2009-08-11 11:13:08 PDT ---
There are at least three distinct related questions in my opinion:

    a) How we detect that there's a change that requires some mouse position
processing.

There are many different types of changes that could trigger the need for this,
such as an element moving that has a CSS cursor associated with it so that it's
no longer under the mouse, any kind of scrolling, or even a change to the CSS
cursor property without any geometry change at all. We need a good architecture
so that the new processing gets done. I don't think it necessarily has to be
done right away. We could use a zero duration or small duration timer to
coalesce these so that multiple changes don't require multiple attempts to
process things, and so that the processing can happen after layout has
occurred.

In fact, when it comes to status bar messages, even changes in the keyboard
state are relevant. For example, if you press the option key on the Mac, we
need to recompute the status message. I believe this is currently done by
simulating a "mousemove" when there is change in the state of modifier keys,
done in the Mac-specific WebKit code.

    b) What should be seen at the DOM level.

For example, if an element moved and that changes the cursor, then presumably
ideally we don't want DOM event handlers to see a DOM "mousemove" event since
the mouse didn't move. Or maybe we do, but if so it's an intentional choice,
not just a side effect of how our code works internally. We might be willing to
live with an excess "mousemove" event, but it's probably not working as
designed if we send one. On the other hand, if an element moves so it's no
longer under the mouse, we probably *do* want to send that object a "mouseout"
event even if we would not have sent a "mousemove" event.

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.

    c) Once we detect a change, how we trigger the additional processing.

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.

(In reply to comment #25)
> 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.

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.

> 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.

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).

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?

> 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.

You're talking about my issue (c) here. But I think that my issue (b) also
comes up. Do we want actual mouse moves to show up in the DOM or not?

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.

> 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.)

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.

> 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.)

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.

You're focusing on issue (c), which is whether a fake mouse event is the best
way to trigger the new processing. We can be flexible on this, but ideally the
code is clear and not full of "fake" anything. I really don't think it's all
that difficult to clean this up and make it right. The degree to which updating
cursors is tied to a PlatformEvent for a mouse move event is actually pretty
small in my opinion.

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