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

Bug 180034

Summary: Draw2d event dispatcher holds mouse capture on mouse up
Product: [Tools] GEF Reporter: Randy Hudson <hudsonr>
Component: GEF-Legacy Draw2dAssignee: Pratik Shah <ppshah>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: ahunter.eclipse, nyssen
Version: 3.3   
Target Milestone: 3.3.0 (Europa) RC1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch for SWTEventDispatcher none

Description Randy Hudson CLA 2007-03-29 12:47:32 EDT
On mouse Up, the event dispatcher still has the mouse target locked until another mouse move occurs on top of a figure which has a mouse listener. Normally the dispatcher immediately fakes a mouse move, but this doesn't work if the figure which handled mouse up has removed itself in response to the mouse up event.

The result is that the event dispatcher locks all mouse events until another figure with a mouse listener is found. Tools in GEF will not function until the mouse moves over such a figure.

A workaround is to use an asyncExec somewhere to avoid moving the figure.
Comment 1 Randy Hudson CLA 2007-04-23 16:50:07 EDT
Pratik, are you interested in trying to create a patch for this?

The problem was something like mouseTarget is not set to null, and code in other places checks if the field is set. Look for calls to asyncExec in our current project.
Comment 2 Pratik Shah CLA 2007-05-15 14:42:10 EDT
Created attachment 67296 [details]
Patch for SWTEventDispatcher

The problem is that the currentEvent is not getting cleared out.  When the figure removes itself, the mouseTarget becomes null, and currentEvent is only ever updated if there's a mouseTarget.  So, the stale event which had been consumed would stay around and prevent any events from propogating to the domain (editor). I've attached a simple patch that clears out the event in SWTEventDispatcher#receive().  I've tested it with our editor and with the logic example (circuit's scrollbars).  I think this fix should be good enough since the currentEvent is only used with the mouseTarget.

Randy, please approve.
Comment 3 Randy Hudson CLA 2007-05-15 17:15:56 EDT
That seems like it would work. The only caller of getCurrentEvent is checking for null already. However, NULL is not mentioned in the javadoc, but the method isn't really "real" API that clients need to be calling. Probably the javadoc should be updated too.

Anthony, can we commit this for RC1?
Comment 4 Pratik Shah CLA 2007-05-18 16:40:49 EDT
Fixed.
Comment 5 Alexander Nyßen CLA 2015-03-20 08:18:10 EDT
Comment on attachment 67296 [details]
Patch for SWTEventDispatcher

Removing iplog+ as contributor was committer (who applied the patch).