Bug 225764

Comment 1 Rüdiger Herrmann 2008-09-04 04:45:07 EDT

The current scope of the key event implementation is to provide the infrastructure necessary to bring Cell Editors to work. E.g. support for text editors is out of scope.

New API introduced:
* There needs to be TraverseEvent/TraverseListener and KeyEvent/KeyListener classes along
  with their respective add/remove methods on Control. These are copied or adopted from SWT.
  Adhering the subset rule of RWT, only those fields, constants, etc that are actually meaningful
  are provided.
* The first attempt is to only support the KeyListener#keyPressed event (no keyReleased).
* The corresponding untyped events (SWT#KeyDown, SWT#KeyUp, SWT#Traverse) will also 
  be supported.
* The modifier mask (KeyEvent#stateMask) to detect Ctrl, Alt, etc keys will be supported if 
  necessary

Key stroke processing:
* A client-side key-stroke-listener is registered in case the server-widget has a KeyListener 
  or a TraverseListener.
* The client-side listener 'knows' whether the server is interested in Key- or a TraverseEvents
  or both. Regardless which server-side listener(s) is (are) attached, the server receives a 
  'generic' notification that a key event occured. In case that only a TraverseListener is to 
  be notified, the request is only sent if a relevant keystroke was detected.
* It is currently anticipated for TraverseEvents to be only 'known' on the server-side. Meaning
  that TraverseEvents are derived from KeyEvents in case that there is such a listener attached
  to the widget.
* This client-side listener 'cancels' the events (stopPropagation) and sends an immediate 
  request to the server.
* On the server-side, a KeyEvent and/or TraverseEvent is fired.
* In case a server-side KeyListener implementation sets the doit flag to true, the event 
  (already suppressed) needs to to be re-thrown on the client-side.

Influence on existing implmenetation:
* Some sort of delegation-mechanism must be implemented for client-side widgets which
  itself have a key listener attached.
* It must be ensured that delayed events (like ModifyEvent on Text widget) do not interfere
  with key events

Possible optimization:
* If TAB key strokes (or maybe other traversal keys?) are detected while a request is running, 
  subsequent key strokes of the same key can be queued until the request returns.
* In order to reduce server-roundtrips, it might prove better to filter key strokes on the client-side 
  and send only key events to the server that are necessary to activate/deactivate a cell editor and 
  to navigate between cells.

Comment 2 Rüdiger Herrmann 2008-10-06 04:55:57 EDT

Created attachment 114286 [details]
Patch that reflects the current development state

* API exists (add(removeKeyListener, KeyListener, KeyEvent)
* Unclear what happens/how to handle repeating key events
* On Firefox, key events are not yet working (after the first keystroke, client-side events aren't blocked until server-response returns)

Comment 3 Rüdiger Herrmann 2008-10-10 11:17:18 EDT

A non-final implementation is in CVS HEAD.
Known issues:
* since Firefox does not suppress input events during synchronous XMLHttpRequest (https://bugzilla.mozilla.org/show_bug.cgi?id=333198), key events that occur while a request is running, are currently discarded.
* the value of the KeyEvent#stateMask field is not yet set
* JavaDoc on Control#addKeyListener that details the limiatations of the RWTversion of key events
* KeyEvent#keyCode might still be wrong for some keys (e.g. F1-F12 on Safari), see http://www.quirksmode.org/js/keys.html

Comment 4 Rüdiger Herrmann 2008-10-20 09:12:14 EDT

An implementation of KeyEvent#stateMask is in CVS HEAD

Comment 5 Rüdiger Herrmann 2008-11-30 07:55:32 EST

Workaround for issue in Firefox which does not allow to programmatically send certain key events.
See also comment in AsyncKeyEventUtil.js

Comment 6 Stephan Leicht Vogt 2011-11-17 05:13:24 EST

(In reply to comment #3)
> A non-final implementation is in CVS HEAD.
> Known issues:
> * since Firefox does not suppress input events during synchronous XMLHttpRequest
> (https://bugzilla.mozilla.org/show_bug.cgi?id=333198), key events that occur
> while a request is running, are currently discarded.
As this bug was solved 2009-02-27 would it be possible to remove the workaround for firefox in AsyncKeyEventUtil.js?

Comment 7 Ivan Furnadjiev 2011-11-17 05:24:56 EST

(In reply to comment #6)
> > Known issues:
> > * since Firefox does not suppress input events during synchronous XMLHttpRequest
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=333198), key events that occur
> > while a request is running, are currently discarded.
> As this bug was solved 2009-02-27 would it be possible to remove the workaround
> for firefox in AsyncKeyEventUtil.js?
I think that this workaround was removed long time ago (before 1.4 release). Currently, all key events (if key/traverse listener is added) are canceled in FF and re-fired again if they are not canceled from the server. No lost of key events. Tim, am I right?