Content Completion related bug on Linux?

[braunse]

In Oxygen XML Editor 25.1 on Linux (OpenSUSE Tumbleweed), I run into a bug, seemingly when I trigger some content completion use cases. I have noticed this when editing XPath expressions in XSLT documents, and when I use ${ syntax in several different file formats (Ant, shell scripts, plain text). It is not clear to me what exactly triggers the bug. When the bug triggers, I can still enter characters, but I cannot use the backspace key, Ctrl+Z or Ctrl+W key combos or the arrow keys. Ctrl+Tab still works, but when I come back to the tab the bug is still active. The only reliable way to get out of this buggy mode is by moving the cursor with a mouse click.

Completion of elements and attributes works fine, as far as I can see.

I have found threads with similar-looking bugs here: Cannot Type in Elements or XPath, Content Completion pop up traps all keyboard inputs. However, the solution given there does not work for me, as there is no jabswitch executable in the Linux installation.

I can reproduce the bug with the following steps under both XFCE and KDE (current versions as packaged by OpenSUSE Tumbleweed):

• Reset Global Options and restart Oxygen XML Editor
• Create a new project in an empty folder
• Create a new "Text" file there named test.txt
• Enter the following text with the keyboard:

  Code: Select all

  ${test(a

  and hit the left shift key.
• The characters (a are now highlighted and the next keystroke will overwrite them.
• Enter a closing paren. The text now reads:

  Code: Select all

  ${test)

• Try to correct by pressing backspace. Nothing happens.

I have no assistive technologies enabled, and have no input methods loaded. I cannot reproduce the bug on Microsoft Windows.

[adrian]

Hello,

We mostly test Oxygen on Ubuntu, in this case for v25.1 it's Ubuntu 22.04. But AFAIK we have not encountered such issues on Ubuntu. I've submitted this scenario for testing to our QA department.

The "similar-looking bugs" are in the context of content completion popup menus and seem unrelated to your issue. As you've seen in those cases it's the Java accessibility mode that causes the issues. But the issues are persistent and immediately visible in those cases. So, IMHO this is unrelated.

The fact that you reproduce this in a plain Text document indicates it may be a keyboard input issue, perhaps between Java and the input source the OS provides. There is no content completion in Text documents, at most you have "Code templates" (code snippets), but there are no predefined code templates for the Text editor. Check if you have custom ones in Options > Preferences, Editor / Content Completion / Code Templates, if there are any for the "Text editor" or for "All editors".

• Enter the following text with the keyboard:

  Code: Select all

  ${test(a

  and hit the left shift key.
• The characters (a are now highlighted and the next keystroke will overwrite them.

Highlighting characters to be replaced isn't a familiar Oxygen behavior. Again, this looks like an input source/input method "feature" that backfires in this case. Java probably facilitates it.

I have no assistive technologies enabled, and have no input methods loaded.

What input source is currently used (Keyboard layout) in the OS settings? Something may be there that you aren't aware of. Perhaps there is an input method that allows for composite characters (e.g. (a) => @ or (c) => ©.
Have you tested the same in a Text editor outside of Oxygen in the same OS?

Regards,
Adrian

[braunse]

Hi Adrian,

thank you very much for your reply. I've been using OpenSUSE on desktop VMs and physical machines for years now and have never noticed this behavior in any other program, including Java-based software like Jetbrains IDE's and Eclipse. I also tried the exact reproduction steps I gave here in IntelliJ IDEA, Eclipse (with the OxygenXML plugins installed) and some other non-Java-based editors (kate, gedit and geany). Everything worked as expected.

I can further reproduce the bug in the most bare-bones environment that I know how to make (fresh install of i3, with out-of-the-box configuration, no Desktop Environment (GNOME/KDE/XFCE), manually killed the fcitx input method daemon, unset $XMODIFIERS.) and I can still reproduce the bug, as long as my keyboard is set to a German layout (the nodeadkeys variant makes no difference). I have not configured any "fancy" compose key options or replacements (as far as I am aware).

However, when I set the keyboard layout to US-English with "setxkbmap us", I cannot reproduce the bug anymore. I then tried a few other layouts and got these results:

• US English(us): cannot reproduce
• French(fr): cannot reproduce
• Romanian(ro): cannot reproduce
• German(de): can reproduce
• Spanish(es): can reproduce
• Polish(pl): can reproduce

This is still under a bare-bones i3 session on my Linux laptop. I don't have an Ubuntu installation to cross-check at the moment.

So there definitely seems to be some interaction between keyboard input configuration and the editor component that Oxygen uses. I still suspect that some application functionality (maybe not completion, could be related to balancing delimiters?) is involved, because the bug depends on the presence of the brace (the dollar seems optional, though). If I enter "test(a" and press the left shift key, I can't trigger the bug. If I enter a very long string like "{testthisisverylongwhywoulditbecomposed(a" the bug still triggers.

Another thing that I noticed is that, when the bug triggers, a thin gray line is displayed at the right edge of the text. I have no idea if that is meaningful, but I have not seen this thin gray line anywhere else.


Sorry for the long post, and once again thank you for your help!

[adrian]

Hi,

Actually thank you for the detailed post.

While I can't reproduce the issue exactly in Ubuntu 22, I can reproduce something very similar with a German (no dead keys) keyboard layout when using AltGr (right Alt key) in combination with Shift to input a capital letter. Are you using the AltGr key?
I've tested and reproduced with:
AltGr+L and AltGr+Shift+L (but can happen in many other combinations)
When Shift remains pressed or is pressed again after AltGr, some of the already input text is selected, the next input character will replace that selection. Backspace key does not work, Esc does not work to avoid this. This mode can only be avoided by clicking the mouse.

I've also noticed that this reproduces even in the Scratch Buffer view, but not in a plain text area (Help > Report problem, Description), so it's possible it's something that our Oxygen editors do to trigger this. I've logged an issue to investigate this. For future reference it's EXM-53014.

Regards,
Adrian

[braunse]

Hi Adrian,

you are right. On a German keyboard, you have to use AltGr to input the {. I have also been able to reproduce the bug with @ € ~ µ \ (all of which use the AltGr key on a German keyboard. I experimented a bit more, and to trigger the bug, it seems that any sequence of the following form can do it:

1. Alt Gr
2. zero or more characters
3. Shift
4. at least one character (or an upper-case combining the shift and another keypress)
5. Shift again

And Oxygen will select anything between the two shift keypresses and enter the buggy mode. The shortest reproduction I found was actually just: AltGr, Shift, a, Shift.

BR,
Sebastien

[braunse]

Hi Adrian (or anyone who can chime in),
any news on this? I just reproduced this bug on a fresh install of Oxygen 26
BR,
Sebastien

[adrian]

Hi Sebastien,

This issue has not been scheduled yet, so it is not fixed in v26.0.

Regards,
Adrian