Bugzilla – Full Text Bug Listing
| Summary: | [Scripting] Calling add-remove-add for same widget/listener removes listener | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Tim Buschtoens <tbuschto> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ivan, tbuschto |
| Version: | 2.2 | ||
| Target Milestone: | 2.2 M2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
I'm guessing calling Widget widget = new SomeWidget() widet.removeListener( SWT.Modify, listener ); widet.addListener( SWT.Modify, listener ); would also yield different results for ClientListener and normal SWT/RAP Listener. This is a regression compared to ClientScripting incubator. The client could support multiple bindings of the same type, see EventBinding.js. This would also align it with SWT behavior where multiple bindings would mean calling the listener multiple times for one event. There are two lists with bindings maintained per request - ClientListenerUtil.ADDED and ClientListenerUtil.REMOVED. I think that server-side fix is better - if the listener is not rendered yet (exists in ClientListenerUtil.ADDED) ClientListenerUtil.clientListenerRemoved should remove it from there. Of course we have to implement ClientListenerBinding#equals and ClientListenerBinding#hashCode. (In reply to comment #3) This would certainly make the message shorter, but it would still not be like SWT, e.g. widet.addListener( SWT.Modify, listener ); //one -new request- widet.addListener( SWT.Modify, listener ); // adds nothing widet.removeListener( SWT.Modify, listener ); // removes the one listener or widet.removeListener( SWT.Modify, listener ); // removes the listener... widet.addListener( SWT.Modify, listener ); // that is added here We need to fix it on both ends I guess. (In reply to comment #4) > Of course we have to implement ClientListenerBinding#equals and > ClientListenerBinding#hashCode. or we just put everything in the same list so the order is preserved (In reply to comment #6) > or we just put everything in the same list so the order is preserved Fixed with commit b6c9ef4e294b0fb2a972d64d592de50615a7c8c1. As of commit 142cdc69d3133f7bd69186ca97bd5c25b9af066c the client also support adding the same listener multiple times. Therefore the bug is fixed. |
For Example: ClientListener listener = new ClientListener( "..." ); widet.addListener( SWT.Modify, listener ); widet.removeListener( SWT.Modify, listener ); widet.addListener( SWT.Modify, listener ); Is rendered in the message as: [call, w6, addListener, {listenerId:r9, eventType:Modify}] [call, w6, addListener, {listenerId:r9, eventType:Modify}] [call, w6, removeListener, {listenerId:r9, eventType:Modify}] Since the client implementation does not allow adding the same listener more than once to a widget/event, it is effectively removed. Also, calling: widet.addListener( SWT.Modify, listener ); widet.addListener( SWT.Modify, listener ); widet.removeListener( SWT.Modify, listener ); is the same, in SWT/RAP one listener would remain, but not when using ClientListener. Not sure whether this should be fixed on client or server.