Community
Participate
Working Groups
On Fedora 29, Eclipse J2EE IDE, pressing Del and holding the button does not produce repeated delete action in any editor.
(In reply to paul deg from comment #0) > On Fedora 29, Eclipse J2EE IDE, pressing Del and holding the button does not > produce repeated delete action in any editor. Does it work on text input fields, e.g. in the Find/Replace dialog?
I faced a bug like this awhile ago on Wayland, are you running on Wayland? I can reproduce the issue in the editor (on Wayland) but not in native text fields (like find/replace, etc.) Build ID: I20190206-1800
Still present on version 2020-06. I can confirm it only happens when running on Wayland and only on the editor, Native GTK widgets work fine. Forcing GTK over X11 on the Wayland session is a workaround. `export GDK_BACKEND=x11` before starting Eclipse.
I have looked into this bug, seems to happen to StyledText only. However, it seems weird that the Delete & Backspace key events are handled differently. I have tested on X11 & Wayland. On both, SWT correctly sends key events for when the delete key is held down. However, on X11 is the 5 key events that were sent actually passed to the StyledText. For some reason, on Wayland these 5 key events don't get passed (only 1). The thing that is weird is that the way the events are handled in between are not up to SWT (from what I saw).
Looks like this is a Platform problem. In AbstractTextEditor, the handling of SWT.DEL action by StyledText is explicitly nullify. Apparently this was done to accommodate this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=51516.
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #5) > Looks like this is a Platform problem. In AbstractTextEditor, the handling > of SWT.DEL action by StyledText is explicitly nullify. Apparently this was > done to accommodate this bug > https://bugs.eclipse.org/bugs/show_bug.cgi?id=51516. So how does it happen to work on X11?
I'm not sure, but the fact that the AbstractTextEdtior nullifies the action of StyledText the event seems to no longer be in control of SWT. The events emitted from X11 & Wayland are exactly the same.
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #7) > I'm not sure, but the fact that the AbstractTextEdtior nullifies the action > of StyledText the event seems to no longer be in control of SWT. The events > emitted from X11 & Wayland are exactly the same. Is it possible that some bundle tries to emulate Delete key after that and this works on x11 but not on wayland?
This issue is still apparent in 2022-09 (4.25) and forcing the X11 backend workaround is still working. I've noticed that in the keyboard shortcut configuration, "Delete" appears as a configured shortcut to "delete text", with no actions specified, and if I remove this keybinding - the Delete key stops working in the styled text editor. There is no such accommodation for Backspace. From the previous discussion, it seems to me that it could be that the Delete key event is nullified in AbstractTextEditor and then is acted upon as a keyboard shortcut. I don't know why it makes it not repeat or why it is only a problem on Wayland.
I experience a similar issue on Windows under some circumstances the Delete key stops working. Usually it works fine after a restart but after a while I note that hitting Del does nothing at all. Backspace still works fine. I use a eclipse installation called sloeber (https://eclipse.baeyens.it/ Eclipse bundled CDT with an Arduino plugin) It is based on eclipse Platform 4.25.0.v20220831-1800 If you need further information, let me know...
Any progress about this? I just switched my Plasma desktop to the Wayland session and I experience the same issue: cancel key repeat does not work, only in text editors, single press works fine, other keys seem to work fine regarding to repeat. Didn't have this problem on X11. Using Eclipse 2023-12 and CDT 11.4.0.202311271618 on ArchLinux.
SWT development moved to https://github.com/eclipse-platform/eclipse.platform.swt . If the issue is not there it would be nice to open new one there - ideally with pure swt reproducer of the issue to ease debugging for when someone finds the time for it.
Issue on GitHub: https://github.com/eclipse-platform/eclipse.platform.swt/issues/938
