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

Bug 338387

Summary: [DateTime] Selection event race condition
Product: [RT] RAP Reporter: Oliver B. <oliver>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: steffen, tbuschto
Version: 1.4   
Target Milestone: 1.4 M7   
Hardware: All   
OS: All   
Whiteboard:

Description Oliver B. CLA 2011-02-28 05:27:43 EST 
The selection event of the DateTime widget is lost, if the widget is disposed before the internal timeout of 500ms expired. This can cause a wrong value on the server side.

In my case it happens in this scenario:

1. A Dialog is opened
2. A DateTime widget is shown with an initial value
3. The user changes the value
4. The user closes the dialog

If this sequence is done fastly, the server has the wrong value for the DateTime widget. The same scenario with a Text widget works fine, because the event is always sent with the next request.

This can also be reproduced with the control demo:

1. Change to DateTime tab
2. Add a selection listener
3. Change the value of the DateTime widget
4. Leave the tab
Comment 1 Tim Buschtoens CLA 2011-03-21 13:05:27 EDT 
Actually, the widget even crashes the application when disposed before sending the changes. Possibly the symptoms of the problem have changed since the version the reporter used. The fix in any case would be to add the parameters immediately and also send the request immediately if a selectionListener is present.
Comment 2 Tim Buschtoens CLA 2011-03-22 06:33:42 EDT 
Fixed in CVS HEAD as described above in DateTimeDate.js and DateTimeTime.js. DateTimeCalendar did not have the issue.
Comment 3 Tim Buschtoens CLA 2011-03-22 06:53:55 EDT 
The fix was no good because the server can now be flooded with events if the spinner is pressed down. I will try to update the fix.
Comment 4 Tim Buschtoens CLA 2011-03-22 07:18:22 EDT 
The problem is with re-introducing the delay that if another widget is selected within that delay (like the original scenario), one of the events will get lost because one Request can only have one WidgetSelected event.
Comment 5 Tim Buschtoens CLA 2011-03-22 09:12:03 EDT 
Fixed in CVS HEAD for good (i think). It now sends the request if the value doesnt change for 100 ms. Its still possible to loose the event if the user is really fast (using a combination of mouse and keyboard for example), but its very unlikely. To fix it 100% we would need the protocol implementation. It cant crash in any case anymore.