GNOME Bugzilla – Bug 345806
Search string truncated if user is a fast typist
Last modified: 2008-03-13 10:32:17 UTC
Please describe the problem: When you press enter, any characters you typed between the last time the list of possible actions was updated and when you press enter are ignored. Steps to reproduce: 1. Click on the Deskbar applet. 2. Type a search string quickly and press enter straightaway. Actual results: Google (or whatever backend) opens up with some of the search string missing. Expected results: I expect Google (or whatever backend) to open with the entire search string. Does this happen every time? Happens every time if you are a reasonably fast typist. Other information: I am using a Pentium M 1.8 with 512 MB RAM and a 7200rpm hard drive. There is no unusual load on the system, and both Deskbar and the rest of GNOME run reasonable fast. Distribution is Ubuntu 606 LTS.
We have some responsiveness tweaks in store that will hopefully eliminate any glitches where deskbar fails to pick up keystrokes (or is just slow to do so) during queries. Developer note: The "responsiveness tweaks" I refer to is to use idle calls for append_matches and query invocations mainly in DeskbarApplet.py
Is this still happenin, i can't reproduce here..
Using Ubuntu 6.06 I get this behaviour still.
Tried hard to reproduce, considering fixed
*** Bug 352059 has been marked as a duplicate of this bug. ***
Just had a dupe, so re-opening. I'll have a try in reproducing.
I can reproduce, like this: Enable Programs(Advanced), and have it top priority in the prefs. Also have dictionary enabled. Type "xkil", and then hit "l<enter>" very fast (pretty hard with my butter fingers). It gives me a dict lookup on "xkil". Is there anyway to flush the event queue for a widget? Maybe doing that just before emitting "start-query" from the CuemiacUIManager...
Bumping this bug severity. We need to have a fix for this before final 2.16 !
I think (and fear) that this is very hard to fix. Atleast there is a lot to consider... Say we do find a way to flush the event buffer on the entry. What if another hit pops to the top of the list in response?
I can reproduce this on Ubuntu Dapper Drake as well
As described in the downstream bug (https://launchpad.net/distros/ubuntu/+source/deskbar-applet/+bug/34024) you can increase the typingdelay in gconf so that it is easier to reproduce and to follow the behavior. I'm not familiar with the deskbar-applet sources nor with the general design of it at all. But let us discuss possible problems on the user side. Personally, I use the deskbar mostly for starting applications. I could also use Alt+F2, but when I use the mouse at the moment anyway it's easier for me to click the deskbar. I often started gaim instead of gvim by accident. So I don't see the problem with unexpected things to happen. When you are typing fast and press enter without waiting, it's clear that you don't want to wait and that you have chosen to trust the software. So the deskbar should do its best not to disappoint the fast typing user and (for example remember what the users last choice was when typing the same string. On the other side we have the unexperienced user. This class of users will wait anyway to see all the choices. The best thing to do here is some kind of activity indicator showing the user that there is possibly more to come in some (milli)seconds. At the moment it seems that the deskbar is indeed waiting typingdelay milliseconds from the last keystroke before starting the searching. That makes sense but an activity-indicator should be shown immediately after each keystroke. And for the fast user... well, as already mentioned, I'm not familiar with the code, but as it seems to be multithreaded, there should be a way to wait for the searching-thread to complete its work before choosing the best option.
I think this bug makes perfect sense to stick on a target milestone, but I don't believe it belongs on the gnome-target; I'm unsetting that field.
I can reproduce this... constantly... sort of anyway :-) I don't think my problem is related to the deskbar waiting for some searching thread to finish, I usually type faster than the delay it seems to take to start searching. I mostly use the deskbar with the keyboard by hitting the accelerator key and then typing very fast what I want. The only problem I have is if the mouse cursor is in the area where the deskbar's dropdown shows up _and_ there is also at least one window on that point too. Then the focus seems to go way to the window and come back in a moment making 2-5 of the keystrokes get lost to that other window that got focused for that little while. So, to me, it seems a window manager/focus problem. Sometimes when this happens the dropdown even gets horizontally maximized like you can see here: http://glua.ua.pt/~rmatos/deskbar_horiz_max.png btw, I'm using: deskbar-applet 2.16.0-0ubuntu4 metacity 2.16.3-0ubuntu2
Rui: That is some pretty spooky stuff, but I think it is unrelated. Would you be so kind as to file another bug on this. You can just copy paste your previous entry more or less... Regarding this bug: Is it a big no-no to set /appps/deskbar/typingdelay to 0 in gconf[1]? When I do it deskbar appears to be a lot more responsive... Also, does this fix the issue for people? [1]: Run "gconf-editor" from a terminal. Browse to /apps/deskbar and right click the list of keys to the right, and select "Add key". Add an Integer key called "typingdelay" and set it to 0.
Just a quick update. I have upgraded to Ubuntu 6.10, and am using its Deskbar package, 2.16.0-0ubuntu4. I can still reproduce the bug in the same way as described above. However, Deskbar's responsiveness has improved noticeably, so I have to type faster than before to reproduce the bug. Although the bug has not gone, the applet is significantly more usable than when I originally reported it. Thanks!
P.S. good news, after setting /apps/deskbar/typingdelay to 0 in gconf I was unable to reproduce the bug (I can reproduce it with the default value of 250).
Setting typingdelay to 0 by default is no good idea, because it will start a new search every time you enter a new letter. That's too much.