The first key press bypasses input method when start searching

[lilydjwg]

Steps to reproduce

1. Login and start Telegram
2. Close any chats. Try to search "中文"

Expected behaviour

As soon as the user starts searching, the input method is ready for use.

Actual behaviour

The input method doesn't activate since there is no focused text input widget. The first key press always bypasses the input method, so you e.g. get z红文 instead of 中文 (pinyin: zhongwen).

This issue starts with version 5.0.

Operating system

Arch Linux

Version of Telegram Desktop

5.0

Installation source

Static binary from official website

Crash ID

No response

Logs

No response

[ilya-fedin]

Do you have an idea how that could be fixed?

[lilydjwg]

Focus the search input box when no chat is open, like 4.x versions?

[ilya-fedin]

@lilydjwg search now seem to have advanced UI when focus happens so it doesn't sound like a good idea. Moreover, it seems it still gets focus automatically in some cases, people don't like that and report such behavior as a bug (#27853)

[lilydjwg]

I see. Could you tell if the user explicitly focuses the search box and only show the advanced UI for empty search string in that case?

I'm also thinking about feeding the key press back into the input method system, but have never seen any application do that. Probably it isn't easy to do so.

[ilya-fedin]

Could you tell if the user explicitly focuses the search box and only show the advanced UI for empty search string in that case?

I guess a more right question is whether such behavior change is wanted as it's made like that on a reason as far as I understand, so it's possible to have narrow chat list without having a chat open.

And, well, if there wouldn't be enough reports about this (e.g. if this is not a problem for Windows or macOS users) then I can imagine behavior change won't be justified to fix this.

I'm also thinking about feeding the key press back into the input method system, but have never seen any application do that. Probably it isn't easy to do so.

The question is how to do that... I'm quite lost in input method related Qt code... I also wonder whether this behavior might be specific to the input method you use and wouldn't be a problem with other ones (leaving the amount of affected users too little for the issue to be prioritized). And in that case, it could be a bug in the Qt plugin for input method you use...

[ilya-fedin]

If you can suggest how I can setup Windows to check this problem, I can do that (in case you can't check Windows yourself)

[lilydjwg]

Yes, it also happens on Windows 10 (I don't have an 11 at hand). It happens with both Chinese and Japanese input methods.

This may not be accurate, but should help: to setup it up, you go to "Settings" app and find the "Languages" page, add a language (e.g. Simplified Chinese; no optional features needed), and switch to it with Super+space, activate with Ctrl+space (IIRC; the Japanese one by default needs a Japanese keyboard to activate so I suggest to test with Simplified Chinese).

[john-preston]

@lilydjwg Yes, I redirect the first keyPressEvent to the field, but I guess for input methods to work that way I'll need to redirect some special events as well. I hope that can be made to work.

[lilydjwg]

but I guess for input methods to work that way I'll need to redirect some special events as well.

I don't think this is possible for the Wayland input method protocol. With that protocol key events first go to the compositor which passes them to the input method when input method is active. There is no way for the application to re-inject it back. The application however could creates a text input, which basically means to use some hidden input focus.

The 4.x version UI worked mostly well. The advanced search UI could be kept hidden if a chat were closed, and only shown when the user clicked the search widget or started to type. #27853 doesn't actually complain about the fact that the search box is focused, but the advanced UI replacing the chat list at a wrong time.

[ilya-fedin]

I don't think this is possible for the Wayland input method protocol. With that protocol key events first go to the compositor which passes them to the input method when input method is active. There is no way for the application to re-inject it back. The application however could creates a text input, which basically means to use some hidden input focus.

Wayland doesn't know the widget hierarchy so I don't see why wouldn't that work? But if you're right then I guess this will just stay broken on Wayland as @john-preston doesn't seem to want to revert the change.

[lilydjwg]

Wayland doesn't know the widget hierarchy so I don't see why wouldn't that work?

The key event won't be sent to input method by the application.

But if you're right then I guess this will just stay broken on Wayland

The QT_IM_MODULE is another way to use input method on Linux. Theoretically you could inject the key event into input method since it's all client-side thing. But the question is how to do that.

I've figured out a way to improve my experience however: press ctrl-f first to focus the search box. This works pretty well as long as I can unlearn the search habit provided by 4.x Telegram.

[ilya-fedin]

The key event won't be sent to input method by the application.

Hmm, isn't that exactly what @john-preston says?

but I guess for input methods to work that way I'll need to redirect some special events as well

[lilydjwg]

There are no such "special events" with the wayland protocol except using a virtual keyboard (which may cause more issues). With the wayland protocol the input method only receives key events from the compositor, which only receives key events from keyboards.

[ilya-fedin]

There are no such "special events" with the wayland protocol except using a virtual keyboard (which may cause more issues).

Not sure you are right. Qt should get those characters from somewhere, there should be some events.

[ilya-fedin]

I'm also not sure Wayland is relevant here, we talk with Qt, not Wayland.

[lilydjwg]

Qt should get those characters from somewhere, there should be some events.

The events need to be forwarded to input method, or the current issue happens.

I'm also not sure Wayland is relevant here, we talk with Qt, not Wayland.

The application talks with input method. Over the Wayland protocol is one way (and for Qt, the other way is QT_IM_MODULE, which talks to input method over D-Bus).

[ilya-fedin]

The application talks with input method. Over the Wayland protocol is one way (and for Qt, the other way is QT_IM_MODULE, which talks to input method over D-Bus).

From application PoV, it sees only Qt. Whatever the way Qt uses under the hood, it usually gets abstracted the same way.

The events need to be forwarded to input method, or the current issue happens.

I'm confused. You was saying

There are no such "special events"

But now you say they do present.

[john-preston]

Ok, I've managed to fix that on Windows :)

[john-preston]

Ok, I've managed to fix that on macOS :)

[ilya-fedin]

@lilydjwg how can I reproduce this on Wayland (I have no idea how to input CJK)?

[lilydjwg]

@ilya-fedin I provide you a description below. If you can't sort it out, I can make a screen record in a cleaner environment but not today.

You install fcitx5 & fcitx5-chinese-addons (the package name may vary), open fcitx5-configtool (it may be in a separate package), search "拼音" from the available list and add it to the left column to enable it:

(I have several, but you only need to add the highlight one besides the first one.)

You switch to the next tab ("Global Options") to check the "activate" shortcut key (the first one, "切换启用/禁用输入法"; I tried to set the language to English but don't know why my interface is in mixed languages). It may be "Control+space".

Depending on your Wayland compositor, you may be able to use the Wayland protocols (KDE: enable fcitx5 in "Settings" -> "virtual keyboards" or the like; wlroots-based: it may just work or not work). You can also use the Qt IM module with e.g. QT_IM_MODULE=fcitx telegram-desktop (the statically-link Telegram contains this IM module).

(The Qt IM module (and the GTK one) is being deprecated though.)

You focus any input field and press the activate key (Ctrl+space, or whatever you noted in the earlier step). Now you type any letters, it should be sent to fcitx5 and an input window appears. If you type "zhongwen", then "1 中文" should appear in that window. The number in front is the key you use to choose the word. The first one can also be chosen by pressing space.

Now you can try to close the chat and search for "中文". You'll notice the the first keystroke doesn't get passed to fcitx5 and later ones do.

[ilya-fedin]

Well. I have a Fedora KDE VM that has Wayland but uses ibus. I also have a Kubuntu VM which uses fcitx but has no Wayland support. Paradox...

Can I configure this with ibus somehow?

[ilya-fedin]

Ok, looks like I managed to set up ibus, the hardest thing was getting im-chooser out of the way

[john-preston]

I hope this will be working on all platforms starting with 5.0.2, but that's some dark magic hacks..

[lilydjwg]

I'm at 5.0.2 now, and it doesn't quite work on Linux Wayland. I'm testing with fcitx5.

With QT_IM_MODULE

The first key is received by IM but the input method window isn't shown. Soon the inputted key gets replaced by the following key, i.e. the first key is effectively lost.

With wayland IM procotol (KDE wayland)

Case 1, with the 拼音 (pinyin) input scheme: The first key is received by IM, but when the search box is focused, that key (preedit string / input state) is reset. The net effect is a flash of input window and then the first key is lost.

Case 2, with the 五笔 (wubi) input scheme: The first key is received by IM, but when the search box is focused, that key is committed as-is. The net effect is a flash of input window and then the first key is inputted as-is like with 5.0.1.

[ilya-fedin]

Hm, it works with IBus on my Fedora VM. I don't have an idea how to fully fix it, perhaps you're right and Wayland is architected in a way that this is just not fixable without a bigger rewrite (which no one would do).