Bug 327887

Comment 1 Tim Buschtoens 2010-10-15 09:12:37 EDT

Created attachment 180953 [details]
snippet

This snippet blocks the request for 3 seconds if a button is pressed. Try pressing all 3 buttons within 3 second, only the first and last will be processed.

Comment 2 Ralf Sternberg 2011-07-28 07:03:03 EDT

The protocol will eventually resolve this issue.
In the meantime, a simple solution would be to exchange the http parameter from
  org.eclipse.swt.events.widgetSelected: w23
to:
  w23.org.eclipse.swt.events.widgetSelected: true

This change should only affect two methods: Request.js#addEvent() on the client and WidgetLCAUtil#wasEventSent() on the server.

Comment 3 Ivan Furnadjiev 2011-07-28 07:16:06 EDT

(In reply to comment #2)
> This change should only affect two methods: Request.js#addEvent() on the client
> and WidgetLCAUtil#wasEventSent() on the server.
I've already have a patch prepared exactly as you suggested. The main effort is the adjusting all server-side tests( mainly LCA test ) and client js tests that fake/check these request parameters. After the patch we have ~100 failing server tests. Didn't check the client tests yet. I'm working on this bug right now.

Comment 4 Ivan Furnadjiev 2011-08-01 12:16:21 EDT

(In reply to comment #2)
> In the meantime, a simple solution would be to exchange the http parameter from
> org.eclipse.swt.events.widgetSelected: w23
> to:
> w23.org.eclipse.swt.events.widgetSelected: true
> 
> This change should only affect two methods: Request.js#addEvent() on the client
> and WidgetLCAUtil#wasEventSent() on the server.
Working on this bug I faced two problems:
1. There are some places where on the client the Request.js#addEvent() is used, but on the server this parameter is not handled by WidgetLCAUtil#wasEventSent(). In these cases the parameter is handled on the server as a standard request parameter.
 - ShellLCA#processActivate - org.eclipse.swt.events.controlActivated event
 - DNDSupport#readControlParam - all DND events (source and target)
 - ActiveKeysUtil#wasEventSent - org.eclipse.swt.events.keyDown event
In these cases, using the approach above does not work as the important variable part (the parameter value) will be part of the parameter key.
2. More of the events have additional event details parameters:
 - Key events: org.eclipse.swt.events.keyDown.keyCode, org.eclipse.swt.events.keyDown.charCode.....
 - Menu detect event: org.eclipse.swt.events.menuDetect.x, org.eclipse.swt.events.menuDetect.y....
 - Mouse events: org.eclipse.swt.events.mouseDown.x, org.eclipse.swt.events.mouseDown.y, org.eclipse.swt.events.mouseDown.time...
 - Selection event: org.eclipse.swt.events.widgetSelected.detail, org.eclipse.swt.events.widgetSelected.item, org.eclipse.swt.events.widgetSelected.index....
In order to avoid parameters replacement we have to make them widget dependent as well. Example:
w23.org.eclipse.swt.events.widgetSelected.item: w34;

Comment 5 Tim Buschtoens 2012-09-27 08:12:20 EDT

Should we consider this bug resolved? With the protocol in place, there are no more limitations to the number and combinations of events attached to a request. However, the way the server processes the message still only fires one event per type AND widget. (Formerly one per type.) So clicking on the same button twice very fast would still not fire two events...

Comment 6 Ivan Furnadjiev 2012-10-01 06:56:21 EDT

(In reply to comment #5)
> Should we consider this bug resolved? With the protocol in place, there are no
> more limitations to the number and combinations of events attached to a request.
> However, the way the server processes the message still only fires one event per
> type AND widget. (Formerly one per type.) So clicking on the same button twice
> very fast would still not fire two events...
Yes... I think that with the new client-to-server protocol in place the bug is resolved.