Version: (using Devel) Compiler: gcc (Gentoo 4.3.0 p1.2) 4.3.0 OS: Linux Installed from: Compiled sources Sometimes when i click on a bookmark or type a www adress in the Address bar and press enter, konqueror freezes for some seconds( ~5-10 ). i can reproduze it: 1) unload the network driver. 2) click on a bookmark. same on bad link quality of my wireless interface.
I have the same problem. Actually I have DSL connection to the internet, but it get's hanged sometimes. At that point if konqueror was requesting some data it hangs completely (no response/redrawing at all).
I can confirm it. But i guess it happens when konqueror sis waiting the result of a dns query, since it happens when connection is down or when i insert a non valid hostname.
*** Bug 189433 has been marked as a duplicate of this bug. ***
I confirm this on 4.2.86 and 4.2.3-svn.
Cannot reproduce with Konqueror 4.2.92.
*** Bug 218818 has been marked as a duplicate of this bug. ***
I have looked into this and found that it's not because of Konqueror doing the lookup in the wrong way, but because of a wrong kurifilter plugin: kdebase/runtime/kurifilter-plugins/fixhost. This plugin attempts to resolve every input given, and in case it can't be resolved, prepends "www." in front of it. Even worse, it then attempts to resolve the new host name, so it could end up resolving two names, each time timing out. I suggest removing this plugin, because: - this bug is very annoying and limits the usability of Konqueror - it does not provide an important feature. For a reference, Google Chrome shows an error when given an invalid URL, without trying to prepend "www.". It does, however, suggest trying an URL with "www." prepended. We could do this in Konqueror. - the plugin makes Konqueror resolve names twice. On systems without local DNS caches, this doubles DNS traffic.
*** Bug 221088 has been marked as a duplicate of this bug. ***
The localdomain filter is presumably affected as well. I'm not very tempted to remove a feature because of a "bug" just because the problem is actually in the network. David: Any idea how to do this without the possible blocking?
Well i think making it asynchronously would help.
*** Bug 214554 has been marked as a duplicate of this bug. ***
I suggest making the following changes to add an asynchronous interface to KUriFilter: - Add a method to KUriFilter: bool filterUriAsync( KUriFilterData& data, const QStringList& filters = QStringList() ); Which in contrast to the similar filterUri() returns true when filtering was done immediatelty, and false when filtering is in progress asynchronously. - Add a signal to KUriFilterData: void filteringDone (bool changed); This is triggered when the filtering is done, after a call to filterUriAsync returned false. The changed argument tells whether the URI was changed. Concerning the plugin interface and compatibility, I have two suggestions: 1. make the KUriFilterPlugin interface asynchronous only. This way it becomes impossible to implement a blocking KUriFilter::filterUri() (AFAIK). Implement it such that when a plugin couldn't filter immediately, ignore the plugin and cancel/disable the async operation of the plugin. 2. extend the KUriFilterPlugin to support both asynchronous and blocking operation. This will provide better compatibility initially, giving developers time do adapt to the new interface without reduced functionality, however it will be harder to develop plugins and change existing ones. Then I suggest deprecating the blocking part of KUriFilter, and fixing programs to use the async interface. What do others think?
My idea some time ago was to fold the fixhost plugin into konqueror, which already performs async stuff when typing a url (KonqRun/KRun), but indeed nowadays with the proliferation of kde-based browsers it might be a better idea to provide a reuseable framework for this. And I hadn't realized that there are two plugins that would be candidates for such a framework already. So yep, your suggestion makes sense to me. Replying to the details about it: I don't think it makes sense to make all uri filters async, many of them are simpler written and used synchronously, like the shorturi filter. Which means option 2, then. (Hmm, I admit I don't really understand option 1, you say impossible and then propose kind of a way to do it...). Anyway I don't want "sync on top of async", this means nested event loops and those are too fragile/troublesome. So if that means "old sync api" has to discard new async filters, ok. That's why that api will be deprecated after all :)
*** Bug 226222 has been marked as a duplicate of this bug. ***
SVN commit 1089327 by pino: backport to kde 4.4: temporarly reduce hostname resolving timeout from 5s to 1s CCBUG: 179746 M +1 -1 fixhosturifilter.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1089327
The issue with the freeze has been resolved since KDE 4.7.0 and further improved since KDE 4.7.1. Starting with the latter version any uri filter plugins that require a DNS query use a multi-threaded DNS lookup that only waits for 1 second and uses an internal cache to greatly cutdown the amount of time it takes to perform such a lookup. There always has been the option of disabling individual uri filters at runtime as well. A lot of people are probably not aware of this functionality. If you do not want any of the uri filters that perform DNS lookup, the you simply disable them by adding a desktop file that contains following: [Desktop Entry] Hidden=true to $KDEHOME/kde4/services/ directory. The desktop file name MUST be <uri-filter-name>.desktop. For example, to disable the "localdomainurifilter", you simply create "localdomainurifilter.dektop" under $KDEHOME/kde4/services/ with the entries listed above.
*** Bug 217294 has been marked as a duplicate of this bug. ***