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

Bug 372773

Summary: [Table] Mouse Events not in sync
Product: [RT] RAP Reporter: Stephan Leicht Vogt <stephan.leichtvogt>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: ivan.motsch, tbuschto
Version: 1.5   
Target Milestone: 1.5 M7   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Bundle to test the behaviour none

Description Stephan Leicht Vogt CLA 2012-02-28 12:44:18 EST 
When clicked fast on a table row the events do not come in the same order as when clicked a tick slower. 
"Slow" and expected order: SWT.MouseDown, SWT.Selection, SWT.MouseUp
Fast order:                        SWT.MouseDown, SWT.MouseUp, SWT.Selection

In SWT the order is every time, no matter how fast clicked with the mouse, the "Slow" order (SWT.MouseDown, SWT.Selection, SWT.MouseUp). This would be the order also RWT should send the events to the client.
Comment 1 Stephan Leicht Vogt CLA 2012-02-28 12:45:45 EST 
Created attachment 211754 [details]
Bundle to test the behaviour

For testing purpose the events MouseDown/MouseUp/Selection generates a sysout. Click fast and click slow will change the order.
Comment 2 Ralf Sternberg CLA 2012-02-29 03:32:36 EST 
This is a known problem. Currently we have to guess the order in which events are fired. Depending on whether the requests arrive in a single request (clicking fast) or several requests, there can be a difference. This issue will be fixed properly when the protocol is installed in the client->server direction, i.e. right after 1.5.

Not sure if we can tweak the event order to workaround it meanwhile - how important is this to you?
Comment 3 Stephan Leicht Vogt CLA 2012-02-29 03:41:39 EST 
It is important as we have already two client complaints concerning this issue. If someone works fast it can easily happen that a field keeps its value because a table does not set its selection right. And subsequently a wrong state is committed to the server. 

Sure, we can defer the issues with the workaround to click a little slower, but I would appreciate it, if you would search a short time for a workaround on your side.
Comment 4 Tim Buschtoens CLA 2012-02-29 04:16:26 EST 
I think this would mean splitting ControlLCAUtil#processMouseEvents, so up and down can be processed independently.
Comment 5 Ivan Furnadjiev CLA 2012-04-23 08:17:44 EDT 
Fixed by order the events (TypedEvent#EVENT_ORDER) by type instead of event class. Related code adjusted to this change.