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

Bug 332083

Summary:

Invalid MouseHover event on MacOSX Cocoa

Product:

[Eclipse Project] Platform

Reporter:

Alexander Nyßen <nyssen>

Component:

SWT

Assignee:

Scott Kovatch <skovatch>

Status:

RESOLVED FIXED

QA Contact:

Silenio Quarti <Silenio_Quarti>

Severity:

major

Priority:

CC:

skovatch

Version:

3.6.1

Target Milestone:

3.7 M5

Hardware:

Macintosh

OS:

Mac OS X

Whiteboard:

Bug Depends on:

Bug Blocks:

242481

Attachments:

Description	Flags
test case	none
Fix	none

Description Alexander Nyßen

2010-12-07 15:21:53 EST

As reported in bug #331993 updating the mouse location via Display#setCursorLocation(Point) or by issuing a SWT.MouseMove event via Display#post(Event) seems to cause an invalid MouseHover event on MacOSX Cocoa.

Comment 1 Scott Kovatch

2010-12-07 18:00:58 EST

Created attachment 184763 [details]
test case

Slightly modified version of the original test case from bug 331993.

Comment 2 Scott Kovatch

2010-12-07 20:11:57 EST

Created attachment 184765 [details]
Fix

This was never really correct. We were getting the current event and getting the mouse location from that but there's no guarantee that the current event will have a valid mouse location.

Comment 3 Scott Kovatch

2010-12-07 20:12:26 EST

This will have to wait for post-M4.

Comment 4 Scott Kovatch

2010-12-13 20:10:52 EST

Fixed > 20101213.

Comment 5 Alexander Nyßen

2010-12-14 16:10:43 EST

Reopening, because using Eclipse 3.7 N20101213-2000, the provided test case still delivers the following result:

Event occured: Event {type=5 Canvas {} time=4027199 data=null x=50 y=50 width=0 height=0 detail=0}
Event occured: Event {type=32 Canvas {} time=4027250 data=null x=0 y=-22 width=0 height=0 detail=0}

That is, the mouse hover returns an invalid location. Also, the broken GEF accessibility mechanism that was the cause for reporting this defect (bug #242481) is not working with N20101213-2000 either.

Comment 6 Scott Kovatch

2010-12-14 20:32:14 EST

(In reply to comment #5)
> Reopening, because using Eclipse 3.7 N20101213-2000, the provided test case
> still delivers the following result:

My checkin for this fix was at 5:10 p.m. Pacific, which means it came in after this build. Try again with the 12/14 build or later. (Technically I did say 'later than 20101213.')

Comment 7 Alexander Nyßen

2010-12-15 01:40:13 EST

Well, sorry for that (I overlooked the >). Verified that with N20101214, the problem does no longer occur.