Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search characters scrambled when typing quickly #113

Open
aleb2000 opened this issue Jul 13, 2024 · 6 comments
Open

Search characters scrambled when typing quickly #113

aleb2000 opened this issue Jul 13, 2024 · 6 comments

Comments

@aleb2000
Copy link

When typing quickly in the search bar it often happens that the search characters are inserted in the wrong order. This seems to coincide with a delay of the app to perform searches on the already inserted terms. It appears to me that when typing the following happens:

  1. I start typing
  2. app freezes briefly due to the app performing the search on what I have already inserted
  3. I keep typing while frozen, the text in the entry does not change as the app is frozen
  4. the results of the previous search are displayed
  5. the characters I typed while the app was frozen are then inserted into the entry in the wrong order

Example of searching "gtk_button_new":

Screencast.from.2024-07-13.16-43-23.mp4

You can see the app visibly freeze when the search starts with "g" as lot of results start with that character. Then the characters "u", "b", "_", and "k" are inserted in the wrong order (I typed it correctly).

It could be that I did not type fast enough to be within the 150ms search delay? Maybe slightly increasing the search delay would help?

Regardless it's quite strange that the other characters are inserted in the wrong order.

@AkshayWarrier
Copy link
Collaborator

Hi, thanks for the bug report. Are you able to reproduce this everytime?

@aleb2000
Copy link
Author

Yes, especially since many functions start with the same prefix, leading to many search results when I start to type something.

@nekohayo
Copy link

nekohayo commented Aug 6, 2024

Wayland or Xorg?

Sounds similar to ibus/ibus#2486 but that was supposed to be solved…

In any case, in terms of workarounds, yes this suggestion here:

It could be that I did not type fast enough to be within the 150ms search delay? Maybe slightly increasing the search delay would help?

Basically, do the same as https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1170 and the myriad of other similar requests I've made elsewhere. There's no reason to have such a low search-delay if your backend is not ultra fast.

@aleb2000
Copy link
Author

aleb2000 commented Aug 6, 2024

Wayland or Xorg?

I did not remember what session I was using at the time of writing this issue, therefore I tested both now. Turns out at the time I was probably using Xorg as the issue does not happen at all on Wayland. On the other hand it is consistently reproducible on Xorg.

I actually made an experiment that gave some interesting results. I logged in with an Xorg session and set the power mode to power saver to increase the time taken by the search even more, I then started typing "gtk_button_new" making sure to pause slightly after the "g" so that the search is triggered (leading to a lot of results starting with g). This way I was able to type my whole search while the app was frozen due to the search happening. When the results where loaded my input in the search bar became: "gwen_nottub_kt". You can clearly see that not only is my input in the wrong order, but it is inserted exactly backwards. I have no idea how this could happen but I find it quite peculiar.

@aleb2000
Copy link
Author

aleb2000 commented Aug 6, 2024

For more context on my system: I am on Fedora 40 with GNOME 46.

@aleb2000
Copy link
Author

aleb2000 commented Aug 6, 2024

This almost looks like the characters are being stored in a stack or something, but I'm sure the problem is probably not that obvious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants