Bug 61211 – Applications can't set a custom mouse cursor by subclassing WKView and overriding WM_SETCURSOR

• Component: WebKit2
• Status: NEW

[Adam Roben (:aroben)]

WebKit2 calls ::SetCursor after every mouse move. This makes it hard for anyone else to set the cursor when the mouse is over a WKView (e.g., if the app subclassed the WKView and wants to change the mouse cursor).

We should only be calling ::SetCursor in response to WM_SETCURSOR. This matches WebKit1 and is what MSDN recommends.

[Adam Roben (:aroben)]

<rdar://problem/9478564>

[Adam Roben (:aroben)]

Created attachment 94266 [details]
Only call ::SetCursor in response to WM_SETCURSOR

[Darin Adler]

Comment on attachment 94266 [details]
Only call ::SetCursor in response to WM_SETCURSOR

How can we trigger a cursor change without moving the mouse, then? Is there some way to cause a WM_SETCURSOR message to be sent even though we are not moving the mouse?

[Adam Roben (:aroben)]

(In reply to comment #3)
> (From update of attachment 94266 [details])
> How can we trigger a cursor change without moving the mouse, then? Is there some way to cause a WM_SETCURSOR message to be sent even though we are not moving the mouse?

You're right that this is an issue with this patch. It turns out I was wrong about WebKit1 only calling ::SetCursor in response to WM_SETCURSOR; it also calls it whenever ChromeClient::setCursor is called.

I have a new patch that fixes the issue for client applications while still allowing the cursor to change without moving the mouse. I'll attach it in a moment. Thanks for reviewing carefully!