Community
Participate
Working Groups
While a http-request is pending, all events of the same type that are attached to the next scheduled request overwrite each other. While the new request is supposed to be send (actually added to the qooxdoo request-queue) after 60ms (Request.js#send), this does not happen because "_sendImmediate" checks the requestCounter and will stall until it is set to a valid vaoue by the response of the pending request.
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.
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.
(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.
(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;
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...
(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.
