Search box completely broken

[php4fan]

Steps to reproduce

1. Type something in the global search box on the top-left
2. Immediately hit Enter, which is something that one usually does after entering a search query in a search box

Expected behaviour

On the left, the search results should be displayed. On the right, either nothing should change (i.e. whatever chat you have open remains there), or it should become empty.

Actual behaviour

The results get updated in real time as you type, but when you hit Enter, whatever randomly happens to be the first result, is selected and opened on the right. Additionally, the search results on the left disappear immediately, and so does the search query. So it's like you never did the search, and somehow magically jumped to some seemingly random chat. You can no longer navigate the search results: you need to re-type your entire query.

In practice, the way to get the search results to show up in the expected way, is to type the search query and refrain from hitting Enter afterwards, which is counterintuitive AF.

Operating system

Manjaro Linux

Version of Telegram Desktop

4.8.1

Installation source

Other (unofficial) source

Crash ID

No response

Logs

No response

[Aokromes]

plz try downloading official static (non-flakpak, non-snap) version from https://desktop.telegram.org

[php4fan]

I got it from the Manjaro packages. Isn't that official enough?

[php4fan]

And are you saying you are unable to reproduce?

[ilya-fedin]

I got it from the Manjaro packages. Isn't that official enough?

No, it's made by third parties

[Aokromes]

And are you saying you are unable to reproduce?

i don't have manjaro, but no cannot reproduce on windows.

[php4fan]

i don't have manjaro, but no cannot reproduce on windows.

Have you tried at least some other Linux distribution? I'd rather not mess with my system.

[ilya-fedin]

The issue template states clearly: If you have no will to install the official binary then you're supposed to report to whoever made the build for you and delegate the task of checking the official binary and further reporting upstream to them. The reporter must be someone who is ready to mess with the system and be ready to check anything at any time (i.e. not just install it when creating the issue and then momentally deleting it) using the official binary, including testing debug binaries.

[php4fan]

The reporter must be someone who is ready to [whatever]

LOL oh ok, if you give so little of a sh** about your own software, or if you are so confident that the issue doesn't exist in the supported version, then go ahead and close. It's not like I'm asking for support, I'm reporting a potential issue.

Just to clarify, when I said "have you tried on some other linux distribution" what I meant was have you tried the official version yourself on any linux machine. Because if you have and have been unable to reproduce, I might feel inclined to make the effort to see if I can install the version you want me to install without messing too much with my system (do I need to uninstall the one I have, will it interfere with something else, where will it be installed, will it leave behind any garbage afterwards, etc - it's work) and see if it reproduces. But if you haven't even tried yourself the version that you claim works (on the relevant OS), then I'm certainly not gonna spend a minute of my time.

(i.e. not just install it when creating the issue and then momentally deleting it)

LMAO

[john-preston]

I'd say it's intended. Enter chooses the first search result. I see the argument about expecting Enter to submit the search, but I don't see an easy way to fix it without breaking an almost ten year learn UX.

[ilya-fedin]

@john-preston this seem to happen only in Qt 6 builds (Linux, macOS), so I don't think there were ten years?

[php4fan]

I'd say it's intended

Then how come nobody seems to be able to reproduce it?

Either way, if it's intented it's intended wrong. It's neither intuitive, nor usable, nor in accordance to common conventions. Read the report again and pay attention to the details.

I don't see an easy way to fix it without breaking an almost ten year learn UX.

I have never seen a search box behave like this in the last ten years, or probably ever.

You may be confusing "chooses the first result" with "choose the SELECTED result".

In the usual cases where enter selects a result, it is usually from some sort of in-situ dropdown, where there is a clear visual indication that the first result is SELECTED (yes I'm screaming), and you usually have a way to unselect it and just submit what you typed.

But again, if any of this was intended the behaviour would be consistent across platforms.

[john-preston]

This search doesn't have a "submit" mechanics, because it auto-submits everything you type.

Ten year UX is Telegram Desktop ten years of working that way. It always was opening the first result (eliminating the need to press down arrow to select the first result that you were filtering the chats list for).

If you're used to it and you always type first letters of the contact / chat name you want to open and press Enter and it was opening for years - and now we stop opening it and just do nothing (the query is already submitted and the list is already filtered etc) and you need to press arrow down and then press Enter again, this will be awful for everyone who is used to existing UX.

[john-preston]

@ilya-fedin This doesn't depend on Qt version.

[ilya-fedin]

This doesn't depend on Qt version.

Why is it working the other way for @Aokromes then? :thinking:

[php4fan]

Ten year UX is Telegram Desktop ten years of working that way

On my linux system (Manjaro with KDE) it only started behaving like this a few weeks ago.

[john-preston]

@ilya-fedin I think he didn't understand the issue correctly. Or maybe I didn't.

[john-preston]

@php4fan I doubt that there was a fairly recent version of TDesktop (last several years at minimum, just to discuss "few weeks") pressing of Enter key after search results appearing didn't choose the first row.

[php4fan]

@ilya-fedin it's still unclear to me whether or not you observe the issue (or the behavior that I report as issue, which is either an issue or a design flaw) and whether you use Linux or Windows or both.

@php4fan I doubt that there was a fairly recent version of TDesktop (last several years at minimum, just to discuss "few weeks") pressing of Enter key after search results appearing didn't choose the first row.

Well that's the behavior that I used to observe on my Manjaro Linux machine, and on my OpenSUSE one before that, and I think also on my Ubuntu one before that (either that or I didn't use Telegram there).

By the way, I'd swear that there has been a short period of a few minutes at some point, after I reported this issue, where I started observing the old (and correct or well-designed) behavior again, and for a moment thought that the issue had gone away. Either I hallucinated/dreamt of it, or this is something that is somewhat random or triggered by pseudo-random conditions, and for some reason, until recently I almost always got the enter-submits behavior, and recently I almost always get the enter-selects-first behavior

[php4fan]

or this is something that is somewhat random or triggered by pseudo-random conditions

OMG I think I've figured out what happens. I'm not 100% sure but this might be it:

If I type fast enough and immediately hit Enter, the search results haven't yet come back by the time I hit Enter, and therefore, Enter does nothing, and I (by sheer accident) get the expected behavior (expected by me at least).

If I don't type fast enough, when I hit enter the results have already come back (possibly not really the results of the full query that I've typed, but the results of some substring of it, that have had the time to come back from the server), and therefore I am selecting the first of those (possibly random) results.

If this is exactly what happens, then:

1. it is a bug even under the assumption that the desired behavior is to select the first result by hitting enter
2. it kind of proves/demonstrates once more that having Enter select the first result is a bad idea, because however you try to solve this, you'll end up with other annoyances or with bad inconsistencies.

[john-preston]

Yes, that is exactly what happens. While the results are not fetched Enter doesn't select anything. The ux flow is that you search for something (by typing the query), you see the results and if the first result is the one you were searching for you just press Enter and choose it.

It works like that for many years, I think for the whole lifetime of Telegram Desktop. At least for the chat filtering I use that every day. You start typing the chat name and when you see it in the first row (the one you want) you hit Enter and start typing a message.

By the way. The search query is dropped and search is cancelled only in case you select a chat that you were searching for (because in 99% of cases you search for a specific chat to start messaging there and when you found it you don't need that search anymore). The local filtering of chats is done instantly, without delay and server requests, so this can't lead to the described behavior of lag between typing and receiving the response.

If you choose a found message (not a chat) or a global search result (a chat, but not from your chats list, from global search by username / name) then the search query isn't dropped and you can choose different results (because it's common to search for a message and go through all the search results one by one). And those results are fetched from the server, so they appear with a delay.

There is a third part of search results. Those are server-provided results for your chats list (the chats that are in your list, but didn't get in the results by client side filtering of chats). This can happen in case some chats were found by that string by the server, but not by the app or in case some chats from your list were not yet loaded in the list so they were not filtered locally, but received from the server. This is the case when a chat can appear with a delay when you type and then drop the search query when you choose it. In that specific case I can stop dropping the search query, maybe this is acceptable and won't bother too many users. Or maybe it will. Idk.

[php4fan]

Well right now I opened (i.e. gave focus to) Telegram Desktop, and for a few minutes it behaved as follows, which is (at least very close to) the old and expected behavior:

I entered a word in a search box, waited several seconds for the results to show up, and only then hit enter.

• the results showed up before I hit enter (at this time that result was not yet highlighted in blue)
• when I hit enter, the first result became highlighted in blue and it did open on the right, BUT crucially, the results remained visible on the left and the query that I typed did not disappear from the search box.

This is sensible behavior.

But then I came here to write this, went back to try again, for a couple of times it kept behaving like this consistently, but eventually after a couple of tries, it has started again exhibiting the stupid behavior when not only hitting enter opens the first result (which by the way is not highlighted before you hit enter, so you don't even have a visual indication that it's the one you're going to open using the Enter key), but also the search results are cleared, the search box is cleared, and the left panel goes back to showing the normal list of chats.

Note that in all cases I'm waiting for the results to show up before I hit enter, so this has nothing to do with having already loaded or not the results.

So the bottom line is: it utterly randomly switches between the two behaviors. The second one is completely wrong, but the fact that it's apparently random (I'm sure there's a criterion that I can't figure out) is even more wrong.

[php4fan]

I have tested a few more times and it keeps oscillating randomly between the two behaviors. I can't figure out what conditions are different, or what I am doing differently (pretty sure the answer to the latter is absolutely nothing) between when I observe one behavior vs the other.

Just for clarity I repeat which are the two behaviors that I randomly observe, BOTH after waiting for the results to show up before I hit enter.

Behavior 1 (correct):

• when I'm finished typing and before I hit Enter, the results show up. None is highlighted (not even lightly)
• when I hit enter, the first result becomes highlighted in blue AND it opens on the right, but
• the query remains in the search box, so I can edit it; and the search results remain on the left, so I can keep exploring them, selecting others instead of the one I have (willingly or accidentally) selected
• I can close the search results and clear the search box whenever I want with the "X" button next to the search box

This is perfect, except for the minor detail that the first result, which is going to be selected and opened when I hit enter, should be somehow slightly highlighted from the start (so that I know that it's the one that I'm going to open with Enter)

Behavior 2 (wrong)

• when I'm finished typing and before I hit Enter, the results show up. None is highlighted in any way
• when I hit enter, the first result gets opened on the right, and
• the search box is cleared, and the search results disappear on the left
• on the left, it goes back to showing the normal list of latest chats

Therefore, I cannot modify my query (without retyping it from scratch) or keep exploring the search results (which is why this behavior is wrong)

(right now I'm desperately trying to get behavior 2 so that I can make sure my description is as accurate as possible, but I'm unable to, despite the fact I observed it a minute ago)

[php4fan]

Oh it looks like this is the criterion that decides whether or not the search is cleared:

The search query is dropped and search is cancelled only in case you select a chat that you were searching for

The application doesn't know what I was searching for, so let me rephrase what you just said:

The search query is dropped and the search is cancelled if the first result that matches my query happens to be the name of a chat rather than the contents of a message in a chat. Which to the user is basically random.

I can be very well searching for a word, looking for a message that contains that word, while at the same time I have a chat whose name happens to start with that word.

The local filtering of chats is done instantly, without delay and server requests

That's completely irrelevant, because I can type faster or slower, and I can be faster or slower in hitting Enter after I'm finished typing (remember, typing a query and hitting enter immediately after is a very common flow, so I'm used to doing it and I cannot be expected to refrain from hitting Enter after I type), so by the time I hit enter, the additional search results from the server may or may not have shown up. In most cases (if not always) the "local" chat will be the first result, so that won't change a thing. Suppose I do it slowly and I behave as you expect me to, that is:

• I type my query (I'm looking for a word or phrase in a message, that I don't know in which chat will be found)
• I happen to have a chat whose name is a match (but it's not what I'm looking for), so that will show up immediately
• I still wait (a fraction of a second or a few seconds more)
• all the results from the server show up, (including hopefully what I'm looking for)
• I hit enter (either [a] because I'm slow and I'm instinctively hitting enter to "submit" my query, or [b] because the first result looks to me like it's going to contain what I'm looking for, i.e. I'm looking for a message with the text "foo" which could very well be in the chat called "Foo" - note that you objected to [a] but you cannot object to [b])
• result: the search is cleared simply because a random coincidence happened. Had I looked for a different word that didn't happen to also match the name of a chat, I could keep browsing my search results and refining my query, but I can't. This is what I call Artificial Stupidity.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!