Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324662

Summary: [Mac] Hand cursor does not appear on Link
Product: [Eclipse Project] Platform Reporter: Praveen <pinnamur>
Component: SWTAssignee: Scott Kovatch <skovatch>
Status: RESOLVED FIXED QA Contact: Silenio Quarti <Silenio_Quarti>
Severity: normal    
Priority: P3 CC: skovatch
Version: 3.6   
Target Milestone: 3.7 M5   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard:
Attachments:
Description Flags
Plugin to reproduce none

Description Praveen CLA 2010-09-07 11:03:26 EDT
Created attachment 178331 [details]
Plugin to reproduce

The problem looks weird to me. I have a view that displays a link. If my application is launched with the view already present in the workbench, then the hand cursor does not appear on the link after the couple of editors are switched.

Steps to reproduce :
1) Please find the attached plug-in - self host the eclipse using this view.
2) Make sure the view is present when the eclipse is launched (next time).
3) Hand cursor appears on the link at this moment.
4) Create 2 Java files - switch between them.
5) The hand cursor does not appear on the links :(

Note: The problem goes away if the view is closed and restarted. Also, the problem occurs only when the view is loaded along with the workbench.

On Cocoa, we set the offsets required for displaying the hand cursor to the platform. This is not clear why the hand cursor is not appearing after the editors are switched.
Comment 1 Scott Kovatch CLA 2011-01-18 18:37:49 EST
On the top of tree of 3.7 I see that when I switch from one Java source file to the other, focus leaves the sample view, so when the mouse goes over the link it remains an arrow. The cursor is only supposed to change when the view is first responder, and that makes sense to me from the platform's perspective.

My hunch is that NSTextView uses an NSTrackingArea to implement the cursor updating. However, in Control#updateCursorRects we call removeTrackingArea when the widget is disabled, and I can see that the link is being disabled when we move from one tab to another. That's bad because we don't own any of the tracking areas the view may have created.

Cocoa only sends mouseMoved messages to tracking areas or the first responder, so I think the best way to handle it is to force an update with mouseMove if we send SWT.MouseMove and the view isn't first responder. NSResponder's mouseMoved: might be called twice, but I haven't seen any harm yet in doing so.
Comment 2 Scott Kovatch CLA 2011-01-18 18:38:21 EST
Fixed > 20110118.