Version: (using Devel)
Installed from: Compiled sources
Open any application which uses KURLCompletion, like Konqueror. In the location bar, Start typing the path of a directory with a bunch of files/directories inside. like / (root directory). You will see that the autocompletion popup doesn't list all the files inside as it should. That's the bug! It din't happen in KDE3, but it happens to me in KDE 4.0.1 and KDE 4.1 trunk.
Note that after having typed the directory (/), if you try once more time to type it (for example remove the character / from the url and then type it again) now it actually list all the files inside.
This happens all over the place, and the problem is probably related to KURLCompletion. It uses some asynchronous look up, which seems to be happening correctly, but the popup is not being updated when new entries are found. The second time the autocompletion is triggered, the result of the last directory is cached and thus it list correctly all the files/dirs.
(I've tried to hunt down and fix this bug, but the code is not trivial and maybe someone more fond of the related code can help me up ;-)
It seems that when you enter for a second time into the directory (/ in the example) you don't necessary get the complete list of files/dirs, but you just get a different one. Something must be broken in the threading thing..
I can reproduce this, but I debugged it far enough to see that the threads are returning the right values, it's just that the widget is never updated.
The basic logic in the completion code is that it first gives the completion thread 200 ms to try to get all of the completions, then it shows the user whatever it got in that time and waits for the thread to finish and then shows the rest of the completions.
The code was written to be multithreaded to avoid situations of the completion code blocking the GUI indefinitely in cases of extremely large directories or sets of users. (On systems that used YP, for instance, on a network with thousands of users sometimes the completion would take several minutes.)
I'm not sure if I'll have time to debug this further than that.
Any news on this?
Can anyone still reproduce this bug with a recent KDE version? (4.1.3 / 4.2beta2 / 4.2svn) ? Thanks :)
Qt: 4.4.3 + qt-copy-patches-889120
KDE: 4.1.86 (KDE 4.1.86 (KDE 4.2 >= 20081221))
kdelibs svn rev. 901624 / kdebase svn rev. 901624
on ArchLinux x86_64 - Kernel 188.8.131.52
It seems to work OK
(In reply to comment #3)
> Any news on this?
> Can anyone still reproduce this bug with a recent KDE version? (4.1.3 /
> 4.2beta2 / 4.2svn) ? Thanks :)
> Qt: 4.4.3 + qt-copy-patches-889120
> KDE: 4.1.86 (KDE 4.1.86 (KDE 4.2 >= 20081221))
> kdelibs svn rev. 901624 / kdebase svn rev. 901624
> on ArchLinux x86_64 - Kernel 184.108.40.206
> It seems to work OK
This is a legitimate bug caused by a logic problem is KURLCompletion::customEvent that causes the creation of a directory listing thread for each and every key you press.
Besides causing an expensive action to occur, it also causes the side effect mentioned in this bug report. Anyways, there is a pending review request that addresses this issue at https://git.reviewboard.kde.org/r/101499/. I will add this bug report to its bugs list.
Git commit d9997d711e493416a35a49cb84700c7b77441211 by Dawit Alemayehu.
Committed on 03/06/2011 at 22:51.
Pushed by adawit into branch 'master'.
- Make executable completion work in OpenWith dialog.
- Fixed the logic error that caused unnecessary creation of directory listing
threads for each and every completion request (read: every key press).
M +9 -9 kio/kio/kurlcompletion.cpp