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

Bug 335589

Summary:

No mouse move events on Cocoa64 unless you press left mouse button

Product:

[Eclipse Project] Platform

Reporter:

Thomas Schindl <tom.schindl>

Component:

SWT

Assignee:

Bogdan Gheorghe <gheorghe>

Status:

RESOLVED FIXED

QA Contact:

Severity:

blocker

Priority:

CC:

alanruttenberg, daniel_megert, gheorghe, kim.moir, Mike_Wilson, ob1.eclipse, pwebster, skovatch

Version:

3.7

Target Milestone:

3.7 M5

Hardware:

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
Patch	none

Description Thomas Schindl

2011-01-27 11:29:44 EST

It looks like some change in SWT broke mouse move listeners and hence a lot of things in the Eclipse UI (e.g. JavaDoc-Hovers).

I currently don't have Eclipse 3.7 builds but this is reproduceable the latest Eclipse 4.1 build (I20110126-2200).

The only possibility to get JavaDoc-Hovers is to press the left mouse button and move the mouse over an element without nothing happens. To find out what happened I've attached a hacked the move mouse listener in org.eclipse.e4.ui.workbench.renderers.swt.SashLayout and it only print debug statements when I press the left button and move the mouse in the area not occupied by the editors and views.

I'd say this is a blocker because it make Eclipse 4.1 fairly unusable for development.

Comment 1 Thomas Schindl

2011-01-27 11:59:54 EST

Could this have something to do with gesture stuff and the system thinks I'm on a touch panel?

Comment 2 Bogdan Gheorghe

2011-01-27 12:03:08 EST

Can reproduce - working on it.

Comment 3 Bogdan Gheorghe

2011-01-27 12:04:39 EST

Not sure - the gesture/touch stuff is high on the list of possible suspects.

Comment 4 Bogdan Gheorghe

2011-01-27 15:13:33 EST

This problem comes from changes made to Display.findControl which is used to determine who to send the MouseMove from. Code was added to take advantage of new API available in 10.6+ (Snow Leopard). The fallback code (for systems less than 10.6) makes use of Carbon calls - which work on 32 bit but fails for 64 bit.

Here's a proposed patch which uses the new API where available and falls back on the old way of locating windows on systems less than 10.6

Comment 5 Bogdan Gheorghe

2011-01-27 15:14:59 EST

Created attachment 187768 [details]
Patch

Scott, if you're OK with the patch, please release it. We need to schedule another I build for tonight. Thanks!

Comment 6 Bogdan Gheorghe

2011-01-27 20:25:31 EST

Fixed in HEAD > 20110127

Ready for a rebuild! (please!)

Comment 7 Scott Kovatch

2011-01-27 20:28:16 EST

Bogdan's analysis is exactly right. I have applied the attached patch for the time being. We'll have to revisit this post-M5.

Fixed > 20110127

Comment 8 alanruttenberg

2011-06-24 16:15:41 EDT

I'm seeing this problem on an application that is being run from within eclipse - specifically protege 4.1 . Instructions at
http://protegewiki.stanford.edu/wiki/CompileProtege4InEclipseFromSvn

Is it possibly related to this bug or should I file another.