Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 321614 - Mouse move events broken in SWT.TOOL shells
Summary: Mouse move events broken in SWT.TOOL shells
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.6   Edit
Hardware: PC Mac OS X
: P3 major (vote)
Target Milestone: 3.7 M1   Edit
Assignee: Scott Kovatch CLA
QA Contact: Silenio Quarti CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 277862
  Show dependency tree
 
Reported: 2010-08-03 11:19 EDT by Markus Keller CLA
Modified: 2010-08-04 11:18 EDT (History)
2 users (show)

See Also:

Attachments
SnippetMouseMove.java (1.68 KB, text/plain)
2010-08-03 11:19 EDT, Markus Keller CLA 		no flags Details
Fix (15.43 KB, patch)
2010-08-03 18:59 EDT, Scott Kovatch CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2010-08-03 11:19:20 EDT 
Created attachment 175787 [details]
SnippetMouseMove.java

I20100802-1800 Cocoa, was OK in 3.6

Mouse move events are broken in SWT.TOOL shells. I don't get any events, but the widgets below the shell get the events.

This can be seen in the attached snippet when you click the button and then move the mouse in the second shell to where it overlaps the StyledText and the Sash.

MouseDown works fine, and as soon as the mouse is down, I also get move events.
Comment 1 Scott Kovatch CLA 2010-08-03 15:58:43 EDT 
To send a mouse moved event we call findControl to see which window/control was hit. So, we scan the list of windows using orderedWindows to return the list of all windows in front to back order. The problem is that SWT.TOOL windows are created as NSPanels, so we can get the utility window titlebar, but NSPanels _are not included_ in the windows returned by orderedWindows!  Arrrggh! So, the SWT.TOOL window will never get a mouse moved event.

Fortunately, I think I can rewrite findControl to not use orderedWindows.
Comment 2 Dani Megert CLA 2010-08-03 16:01:58 EDT 
What caused the regression compared to 3.6?
Comment 3 Scott Kovatch CLA 2010-08-03 17:12:27 EDT 
SWT.TOOL windows now are implemented via NSPanel (bug 218929), since that's the only way you can set the NSUtilityWindowMask to get the thinner title bar. That was a small change, but it turned out to have a lot of subtle consequences. They also hide on deactivate, which ends up hiding the parent window in SWT.
Comment 4 Scott Kovatch CLA 2010-08-03 18:59:24 EDT 
Created attachment 175812 [details]
Fix

Use the full window list when looking for the window under the mouse.
Comment 5 Scott Kovatch CLA 2010-08-03 19:00:03 EDT 
Fixed > 20100803.
Comment 6 Dani Megert CLA 2010-08-04 02:19:08 EDT 
(In reply to comment #1)
Thanks Scott for the detailed explanation. Can you make sure this gets released for M1? Thanks!