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

Bug 511975

Summary:	Ensure FXCanvasEx does not accumulate SWT key down events when pressing and holding a key
Product:	[Tools] GEF	Reporter:	Matthias Wienand <matthias.wienand>
Component:	GEF FX	Assignee:	gef-inbox <gef-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	1.1.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Matthias Wienand

2017-02-09 09:07:50 EST

Currently, FXCanvasEx ensures that JavaFX keyboard events (which are generated from SWT keyboard events) are consumed when the underlying SWT event has the "doit" flag set to false. Therefore, a list of unprocessed SWT keyboard events is maintained by FXCanvasEx.

When a key is pressed and hold down for some time, SWT will generate repeated key down events with a constant delay in-between. When the corresponding JavaFX events are dispatched, key down events may not be directly removed from the list of unprocessed events, because JavaFX fires KEY_TYPED events in addition to KEY_PRESSED and KEY_RELEASED. That's why FXCanvasEx only removes the key down events when dispatching the JavaFX KEY_RELEASED event.

However, only a single key down event is removed from the list of unprocessed events when dispatching KEY_RELEASED. Therefore, the other key down events that resulted from SWT key repetition stay in the list of unprocessed events.

We should ensure that these events are not accumulated, so that the list of unprocessed events is empty after releasing all pressed keys.

Comment 1 Matthias Wienand

2017-02-10 06:50:56 EST

I simplified the relationship between unprocessed SWT key events and generated JavaFX key events. As soon as a JavaFX key event is dispatched, the corresponding SWT key event is directly removed from the list of unprocessed events. The last SWT key down event is cached so that its "doit" flag can be checked when dispatching a JavaFX KEY_TYPED event. The code is published on the master branch, therefore, I resolve this ticket as fixed for 5.0.0 M6.