Bug 61211 - Applications can't set a custom mouse cursor by subclassing WKView and overriding WM_SETCURSOR
Summary: Applications can't set a custom mouse cursor by subclassing WKView and overri...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar, PlatformOnly
Depends on:
Blocks: 61213
  Show dependency treegraph
 
Reported: 2011-05-20 13:45 PDT by Adam Roben (:aroben)
Modified: 2011-05-23 07:35 PDT (History)
2 users (show)

See Also:


Attachments
Only call ::SetCursor in response to WM_SETCURSOR (1.79 KB, patch)
2011-05-20 13:53 PDT, Adam Roben (:aroben)
aroben: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2011-05-20 13:45:34 PDT
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.
Comment 1 Adam Roben (:aroben) 2011-05-20 13:46:13 PDT
<rdar://problem/9478564>
Comment 2 Adam Roben (:aroben) 2011-05-20 13:53:51 PDT
Created attachment 94266 [details]
Only call ::SetCursor in response to WM_SETCURSOR
Comment 3 Darin Adler 2011-05-20 13:55:40 PDT
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?
Comment 4 Adam Roben (:aroben) 2011-05-23 07:33:59 PDT
(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!