IME candidate box appears in wrong location in ver 5.5.1

[YanceyChiew]

Steps to reproduce

1. Upgrade tdesktop to version 5.5.1.
2. Open the main window and use fcitx5 to enter content in any chat.
3. Switch cursor focus in the chat window and search bar, then continue typing.

Expected behaviour

The candidate box popped up by the IME should move with the input cursor focus position.
The previous version works just fine.

Actual behaviour

The IME candidate boxe may not show up at all until one manually switch input cursor focus to another widget.

When the candidate box pops up, it may appear on the penultimate widget that has got focus. For example, you are currently typing in the chat window, but the IME candidate box floats on the search box, vice versa.

Even if the candidate box pops up correctly in the chat input box, it will be displayed in a relatively fixed position and will not be accompanied by the movement of the cursor position, unless the cursor switches to another widget, such as the search box, and then in the search box subsequent Input will pop up a candidate box at the last position of the cursor in the previous chat input box.

Moving the window will cause the candidate box to fail to pop up, and switching the widget that inputs text can be restored.
So I suspect that the candidate box will always pop up at the last cursor position of the penultimate focused widget when another (possibly the same type, but in different chat) widget that also supports text input gets focus. Because the cursor position in the penultimate text input box that receives focus will not change with the current input, the candidate box will be fixed.

Pasting text can also cause the candidate box to pop up. Pasting text of different lengths and then switching chats to try input can verify the previous inference.

Operating system

Debian GNU/Linux trixie/sid with GNOME Shell 46.4 on Wayland

Version of Telegram Desktop

5.5.1

Installation source

Static binary from official website

Crash ID

No response

Logs

QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter
QTextCursor::setPosition: Position '4' out of range
QTextCursor::setPosition: Position '3' out of range
QTextCursor::setPosition: Position '4' out of range

---

QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter
QTextCursor::setPosition: Position '8388607' out of range
QTextCursor::setPosition: Position '8388607' out of range

[ilya-fedin]

Not sure what could be done here - Qt update is likely the cause

[ilya-fedin]

2. Open the main window and use fcitx5 to enter content in any chat.

How do I do the

use fcitx5 to enter content in any chat

part?

Just installing fcitx5 doesn't seem to lead to any "candidate windows".

[YanceyChiew]

Just installing fcitx5 doesn't seem to lead to any "candidate windows".

If you want to build a test environment, in addition to installing fcitx5 itself, you also need to install fcitx5-modules. Some modules in it provide wayland support for fcitx5.

Then install an input method that uses the fcitx5 framework and requires compose input and provides a list of candidate words. The fcitx5-pinyin is used here.

Besides, you also need fcitx5-frontend-all, which introduces fcitx5-frontend-qt5 and fcitx5-frontend-qt6 as dependencies. The fcitx5 will recommend installing it, so there is generally no need to install it manually.

---

update:

Pasting text can also cause the candidate box to pop up. Pasting text of different lengths and then switching chats to try input can verify the previous inference.

Pasting is not necessary, and pasting using the keyboard shortcut won't work here, all that does the trick is a right-click on the input box.

So my guess is that clicking the left mouse button repeatedly in the same input box will not trigger setting a unknow certain property related to the cursor position more than once, but alternating right and left clicks will.

Not sure what could be done here - Qt update is likely the cause

Therefore, this clue may be able to help locate the problem. If the problem is caused by Qt update, a temporary workaround can also be made by responsively setting the cursor position once more when the cursor position changes., although if this is the case, waiting for Qt to be fixed is the best option.

[ilya-fedin]

Then install an input method that uses the fcitx5 framework and requires compose input and provides a list of candidate words. The fcitx5-pinyin is used here.

Should I just add a group with chinese layout? If yes, this doesn't seem to work for me, it still inputs english even though it shows "zh" above the input field.

[YanceyChiew]

Should I just add a group with chinese layout? If yes, this doesn't seem to work for me, it still inputs english even though it shows "zh" above the input field.

This is enough for me, I'm not sure what is usually missing in non-Chinese locale devices.

You can try adding locale zh_CN.UTF-8 and installing a Chinese font like fonts-noto-cjk, which may solve the problem.

Here are two reference links for more detailed explanations:

• https://wiki.archlinux.org/title/Fcitx5
• https://wiki.debian.org/I18n/Fcitx5

Or have you tested it in other programs? The 5.5.1 version of tdedsktop cannot directly pop up the IME candidate box, which is the expected behavior of this issue.

[ilya-fedin]

Looks like I forgot to install fcitx5-pinyin, now I have pinyin exactly rather than just chinese layout

[ilya-fedin]

Seem to work just fine for me

[YanceyChiew]

Seem to work just fine for me

Are you sure that tdesktop is currently running under gnome's wayland session? Because I can always reproduce this issue.

When I saw your reply, my tdesktop happened to be back to normal, which made me mistakenly think that it was just a small bug related to the settings -> interface scale migration during the upgrade. It can be restored by simply maximizing the window.

This is because, in order to test whether the issue is only related to gnome, I opened tdesktop and fcitx5 in another hyprland session, and the problem was successfully reproduced.

After I closed the hyprland session and reopened tdesktop and fcitx5 in the gnome session, I didn't realize that gnome-shell's environment variable WAYLAND_DISPLAY was tainted with hyprland, and apps opened from the desktop would fail to connect to WAYLAND_DISPLAY and fall back to x11 backend, and everything is normal under x11.

If gnome's font scaling was adjusted, the default interface scale value of tdesktop is different under x11 and wayland, so I have been using the manually set interface scale before.

When I noticed that after the tdesktop window was opened and accidentally maximized, the font size became smaller and the IME candidate box became normal again. I just mistakenly thought that there was some causal relationship between them.

After reinstalling the old version and upgrading to the new version many times in an attempt to reproduce the problem, I accidentally discovered that it had just fallen back to the x11 backend.

[ilya-fedin]

Are you sure that tdesktop is currently running under gnome's wayland session?

I use KDE neon with Plasma Wayland session for testing. If this happens only under GNOME, this might be yet another GNOME's Qt incompatibility.

[YanceyChiew]

I use KDE neon with Plasma Wayland

I learned from a netizen in a chat room that the updates of kde and tdesktop have fixed the problem of random incorrect position of the fcitx5 candidate box that he had encountered before, so things should be different on kde.

I can reproduce it on both gnome and hyprland.

[ilya-fedin]

Well, that's the only environment I have to test on. And I can't reproduce.

[ilya-fedin]

Most likely both GNOME and hyprland should invest into Qt compatibility.

[YanceyChiew]

Most likely both GNOME and hyprland should invest into Qt compatibility.

I was surprised to find that the same problem also occurred in the previous version of tdesktop, so it can be considered that it was not the incompatibility introduced by the tdesktop upgrade, but the restart process caused by the upgrade that made some external changes take effect.

Because the automatic upgrade of tdesktop is difficult to turn off, it was upgraded as soon as I opened the program, and I needed to log in again to use the downgraded version again, so I didn't find out until the end.

Finally I found the reason. Earlier I set an environment variable referring to this document: QT_IM_MODULES="wayland;fcitx"

This allows me to use fcitx5 normally within tdesktop running under a wayland session. But what actually happens is that it may not take effect, or the wayland module at the front of the sequence fails, so that the fcitx module can be selected.

I'm not really sure about this inference, because using QT_IM_MODULE="wayland" alone works fine, and tdesktop is not dynamically linked to the external im module, so I can't see which module is actually loaded.

Anyway, simply unsetting the environment variable or changing the order of the values​​ to QT_IM_MODULES="fcitx;wayland" can solve this problem.

---

Thank you very much for helping me solve this issue.

Although the root cause of the problem is not clear, we already have simple and effective ways to avoid it, and I hope this helps others facing the same situation.

[ilya-fedin]

Because the automatic upgrade of tdesktop is difficult to turn off

Just disable in settings?

Anyway, simply unsetting the environment variable or changing the order of the values​​ to QT_IM_MODULES="fcitx;wayland" can solve this problem.

Do you have QT_IM_MODULE also set? What might happen here is that the Wayland IM protocol implementation is bugged either by GNOME/Hyprland or Qt while fcitx's own plugin works properly.

[ilya-fedin]

If I'm not mistaken, KDE implements text-input-v2 while GNOME implements only text-input-v3 but the latter is implemented only recently in Qt and is pretty bugged so it's likely better to not to set QT_IM_MODULE(S) to wayland on GNOME.

[YanceyChiew]

Just disable in settings?

Unless I move very quickly, or the Internet speed happens to be very slow, usually the update has already been downloaded when I open the settings. Once the download is complete, even if automatic updates are turned off, the next time I open it, it will still be the new version. I tried to cancel the write permission of the parent directory of the tdesktop program, so that the program cannot be replaced, but the login status will also be invalid, then I need to log in again to open the program with the same path. Once the executable is upgraded, I replace it with the old version but the settings are reset...

Do you have QT_IM_MODULE also set? What might happen here is that the Wayland IM protocol implementation is bugged either by GNOME/Hyprland or Qt while fcitx's own plugin works properly.

No, I used QT_IM_MODULE before, but switched to QT_IM_MODULES some time ago, and it worked for a while. I think your inference is very reasonable.

If I'm not mistaken, KDE implements text-input-v2 while GNOME implements only text-input-v3 but the latter is implemented only recently in Qt and is pretty bugged so it's likely better to not to set QT_IM_MODULE(S) to wayland on GNOME.

After restarting the computer just now, I tested specifying QT_IM_MODULE=wayland in the environment variable and found that its behavior is consistent with the behavior originally described in this issue, but it was working normally when I wrote the previous reply. I was still confused at first, but when I saw this I think the test just now may happened on an old version of tdesktop.

Now change the environment variable back to QT_IM_MODULES="fcitx;wayland", and I can type happily on tdesktop again.😋

[ilya-fedin]

Unless I move very quickly, or the Internet speed happens to be very slow, usually the update has already been downloaded when I open the settings.

Remove the tupdate folder inside the data folder / near the tdata folder...

[YanceyChiew]

Remove the tupdate folder inside the data folder / near the tdata folder...

Got it, thank you!

Next time I encounter a similar situation, I won't be so embarrassed.