Created attachment 68053 [details] Patch to fix Windows specific code, you can see that the condition in the while loop is pretty weak and can lead to an infinite loop if the result of 'url.upUrl()' is 'url' Version: unspecified (using KDE 4.7.4) OS: MS Windows While investigating BUG 291850 I came across this issue. I've fixed BUG 291850 using a workaround (call KFileDialog::getExistingDirectoryUrl() instead which opens the native directory selection dialog). The problem is that KDirSelectDialog::selectDirectory causes an infinite loop (see the attached patch for the reason). Reproducible: Always Steps to Reproduce: Call KDirSelectDialog::selectDirectory() from an application. Actual Results: Infinite loop plus a series of failed assertions. Expected Results: Select a directory without problems.
Hi, cool that you found this, what is the top level url KUrl url.upUrl() returns when you call it often enough? I would have expected it to be the same on Windows as on Linux (file:///) if that is not the case this bug might be a symptom of a bug in kurl. I would think that "Call upUrl until you are on on the root" would be a strong enough break condition as long as it is clearly defined that infinite calls to upUrl on a local file url return file:///
If I remember correctly it was returning 'file:///C/' when the initial URL was a directory under C:/. But you can test this easily by calling KFileDialog::getExistingDirectoryUrl() and trying to navigate trough the directory structure. Once you click a directory to enter it this bug occurs.
I had this problem in Kontact before (when opening attachments) that some kde code assumes that file:/// points to the root directory but in fact according to RFC 1738 A file URL takes the form: file://<host>/<path> So on Linux file:/// does not point to anything at all while on Windows file:///C/ points to the assumed root directory. Having different behavior there is bad. The problem i see is that a fix to KURL to ultimately just return file:/// or file://// on linux and file:///C/ could lead to regressions.
This bug is fun. According to the documentation: http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKUrl.html#a5a89a0a2d5af55d75e808cc029a24172 "The algorithm tries to go up on the right-most URL. If that is not possible it strips the right most URL. It continues stripping URLs." So you would expect to end up with file:/// on Windows too (everything is stripped in the end) But in the implementation: http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/kurl_8cpp_source.html#l01475 it basically does cd .. (So you would expect to end up with file://// on Linux and file:///C/ on Windows) I would say the correct fix here would be to end up with file:/// on windows and linux because ultimately when you go upDir you want to end up on something like a drive overview and not on the current drive. Which would also be according to the documentation that it strips the rightmost url until no more url is left.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.