Version: 4.6 (using KDE 4.5.95) OS: Linux Hi, Reproducible: Always Steps to Reproduce: 1) Use rekonq (latest git here) or Konqueror 4.5.95 with kwebkitpart (latest git too) 2) go to www.wikipedia.org 3) type something in the searchbox, for example "KDE" and hit enter Actual Results: Both rekonq and konqueror are showing a loading progress but they don't go to the result page : http://en.wikipedia.org/wiki/Kde in this this example. Instead they are staying on www.wikipedia.org Expected Results: I expect to be redirect to the results I'm looking for. Works without problem with arora, which leads me to think it's a kdewebkit issue.
(In reply to comment #0) > Version: 4.6 (using KDE 4.5.95) > OS: Linux > > Hi, > > Reproducible: Always > > Steps to Reproduce: > 1) Use rekonq (latest git here) or Konqueror 4.5.95 with kwebkitpart (latest > git too) > 2) go to www.wikipedia.org > 3) type something in the searchbox, for example "KDE" and hit enter > > Actual Results: > Both rekonq and konqueror are showing a loading progress but they don't go to > the result page : http://en.wikipedia.org/wiki/Kde in this this example. > Instead they are staying on www.wikipedia.org > > Expected Results: > I expect to be redirect to the results I'm looking for. > > Works without problem with arora, which leads me to think it's a kdewebkit > issue. That assumption would only be true if you cannot reproduce the issue with konqueror + khtml as well. I personally tried this and cannot reproduce it here.
It works with konqueror + khtml. So if it works for you any idea where the problem could come ? a config file, a cache folder or something like that ? I have this problem (and others redirection problem) since a long time ago and I'm using a new and clean ~/.kde4 folder since KDE 4.6beta. thanks.
Forgot to mention that clicking on any language on the default wikipedia frontpage doesn't load the page either.
(In reply to comment #2) > It works with konqueror + khtml. > So if it works for you any idea where the problem could come ? a config file, a > cache folder or something like that ? I was going to suggest you clear your cache and try again but since you stated that everything works fine in konqueror + khtml, that cannot be the cause... I do not know what to tell you except to try and enable the debugging are for konqueror and start it from konsole and see what it spits out: 1.) Press ALT+F2 2.) Enter kdebugdialog 3.) In the Search field type konqueror 4.) Make sure konqueror appears and the checkbox besides it is checked. 5.) Press Apply and then OK. > I have this problem (and others redirection problem) since a long time ago and > I'm using a new and clean ~/.kde4 folder since KDE 4.6beta. Other redirection problems ? Hmm... do you have an example of one of those as well ?
The only line that appears when clicking on language link in wikipedia, french for example, is this : konqueror(10772)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( "http://fr.wikipedia.org/" ) , type: 0 , frame: QWebFrame(0x77a610) same with english language link : konqueror(10772)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( "http://en.wikipedia.org/" ) , type: 0 , frame: QWebFrame(0x77a610) Another example of this is on http://www.onnouscachetout.com/ When I click on forums link (on the left side) nothing happens. Again : konqueror(10772)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( "http://www.onnouscachetout.com/forums" ) , type: 0 , frame: QWebFrame(0xf6dfd0) Another thing that come to my mind now, is that i'm using squid as a local cache. Could it be the problem ? I dont have time to make further testing right now, but I have this problem only with rekonq and konqueror/webkit, no problem with firefox,chromium,arora,konqueror/khtml.
(In reply to comment #5) > The only line that appears when clicking on language link in wikipedia, french > for example, is this : > konqueror(10772)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( > "http://fr.wikipedia.org/" ) , type: 0 , frame: QWebFrame(0x77a610) > > same with english language link : > konqueror(10772)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( > "http://en.wikipedia.org/" ) , type: 0 , frame: QWebFrame(0x77a610) > > Another example of this is on http://www.onnouscachetout.com/ > When I click on forums link (on the left side) nothing happens. Again : > konqueror(10772)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( > "http://www.onnouscachetout.com/forums" ) , type: 0 , frame: > QWebFrame(0xf6dfd0) That is good enough... What that shows you is that the request made it all the way to QtWebKit. Your clicks actually work and are handled properly by QtWebKit. Now, you have to determine where the networking layer is doing its job and you can do so by following the same guideline I gave you in comment #4, but enabling the debug area 7044 instead of Konqueror. IOW, in step #3 type 7044 instead of Konqueror and follow all the other steps... > Another thing that come to my mind now, is that i'm using squid as a local > cache. Could it be the problem ? It most definitely could be. You should try it without going through the squid cache to see if the problem goes away. If it does, then I suggest you disable KDE cache from Konqueror's configuration dialog box. If you have a local squid cache, it is pointless to have the local KDE one as well. > I dont have time to make further testing right now, but I have this problem only > with rekonq and konqueror/webkit, no problem with firefox, chromium, arora, > konqueror/khtml. Hmm... the problem is only with the kdewebkit based browsers ? Then the above suggestion I made makes no sense, but still try it and see if it resolves your problem.
Thanks for your answers. I tried yesterday to disable squid, no success. I also deleted cache folder and disabled konqueror cache but it's not helping. This are the new output with kio AccessManager debug : - Clicking wikipedia french language link : konqueror(12321)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( "http://fr.wikipedia.org/" ) , type: 0 , frame: QWebFrame(0x161c610) konqueror(12321)/kio (AccessManager) KDEPrivate::AccessManagerReply::slotResult: 124 - Typing "KDE" in wikipedia (frontpage) search box : konqueror(12321)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( "http://www.wikipedia.org/search-redirect.php?search=KDE&language=fr&go=++→++&go=Go" ) , type: 1 , frame: QWebFrame(0x161c610) konqueror(12321)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( "http://fr.wikipedia.org/wiki/Special:Search?search=KDE&go=Go" ) , type: 1 , frame: QWebFrame(0x161c610) konqueror(12321)/kio (AccessManager) KDEPrivate::AccessManagerReply::slotResult: 124
(In reply to comment #7) > Thanks for your answers. > I tried yesterday to disable squid, no success. I also deleted cache folder and > disabled konqueror cache but it's not helping. > > This are the new output with kio AccessManager debug : > > - Clicking wikipedia french language link : > konqueror(12321)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl( > "http://fr.wikipedia.org/" ) , type: 0 , frame: QWebFrame(0x161c610) > konqueror(12321)/kio (AccessManager) > KDEPrivate::AccessManagerReply::slotResult: 124 ^^^^ The 124 message is an error code and according to the KIO::Error list 124 is ERR_UNSUPPORTED_ACTION. No idea why you would get that with the kdewebkit based browsers, but not khtml... The only thing left to do to troubleshoot this is to save the output of kio_http to file and compare what you get when you use khtml vs kwebkitpart at that level. Here are the steps to save the http debug output to file: 1.) Press ALT+F2 2.) Enter kdebugdialog --fullmode 3.) Select debug area 7103 kio_http 4.) Select "File" in the Output to box of the "Information" group. 5.) Chosse a file to output to, e.g. /tmp/kio_http.log. 6.) Press Apply. 7.) Repeat steps 3-6 for debug area 7113 kio_http_debug. 8.) Press Ok. 9.) Log out of your KDE session and log back in for the change to take effect. Run your tests for both konqueror + kwebkit and konqueror +khtml, scrub the produced log file for any personal information you want to protect and attach the log file here...
Created attachment 56370 [details] kio_http_debug
In the attachment comment#9 I went to wikipedia.org an clicked on french language link : - first with webkit, fr.wikipedia.org appears line 1156 - then with khtml, fr.wikipedia.org line 3022 Thanks.
Hi, I don't know if you had free time to look at the log file but when I enable the network analyzer (developer tools) in rekonq, for every links not working as expected, I get a "301 Moved" answer/response and the length of the message is always 20. Don't know if it can help or give a clue about this issue... Thanks.
(In reply to comment #9) > Created an attachment (id=56370) [details] > kio_http_debug Way too much information in this log file... what you should do is go to the site, e.g. wikipedia.org and right before you are going to carry out the test, delete the the kio_http debug output file (don't worry it will be recreated). That way when do the test the first request would be the test request and makes it much easier to follow that is going on...
Created attachment 56432 [details] kio debug KHTML First request is a click on french language link on wikipedia.org
Created attachment 56433 [details] kio debug WebKit same as previous log bug with webkit engine
Well I see what the problem is and why it potentially works in khtml but not kdewebkit. When you visit fr.wikipedia.org, you get the following error in both cases: kio_http(21091)/kio_http_debug HTTPProtocol::readResponseHeader: Content-type: "text/html" kio_http(21091)/kio_http_debug HTTPProtocol::readResponseHeader: Encoding-type: "charset" = "utf-8" kio_http(21091)/kio_http_debug HTTPProtocol::readResponseHeader: Re-directing from "http://fr.wikipedia.org/" to "http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal" kio_http(21091)/kio_http_debug HTTPProtocol::cacheFileClose: kio_http(21091)/kio_http_debug HTTPProtocol::fixupResponseMimetype: before fixup "text/html" kio_http(21091)/kio_http_debug HTTPProtocol::fixupResponseMimetype: after fixup "text/html" kio_http(21091)/kio_http_debug HTTPProtocol::proceedUntilResponseHeader: Previous Response: 0 kio_http(21091)/kio_http_debug HTTPProtocol::proceedUntilResponseHeader: Current Response: 301 kio_http(21091)/kio_http_debug HTTPProtocol::readBody: "20" bytes left. kio_http(21091)/kio_http_debug HTTPProtocol::readBody: bytesReceived==-1 sz= 0 Connection broken ! which causes the 124 error, which I incorrectly stated was ERR_UNSUPPORTED_ACTION in comment #8. It is actually ERR_CONNECTION_BROKEN which is exactly what happens above. I do not get a connection brokwn when I visit fr.wikipedia.org: kio_http(1571)/kio_http_debug HTTPProtocol::readResponseHeader: Re-directing from "http://fr.wikipedia.org/" to "http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal" kio_http(1571)/kio_http_debug HTTPProtocol::cacheFileClose: kio_http(1571)/kio_http_debug HTTPProtocol::fixupResponseMimetype: before fixup "text/html" kio_http(1571)/kio_http_debug HTTPProtocol::fixupResponseMimetype: after fixup "text/html" kio_http(1571)/kio_http_debug HTTPProtocol::proceedUntilResponseHeader: Previous Response: 0 kio_http(1571)/kio_http_debug HTTPProtocol::proceedUntilResponseHeader: Current Response: 301 kio_http(1571)/kio_http_debug HTTPProtocol::readBody: "20" bytes left. kio_http(1571)/kio_http_debug HTTPProtocol::readBody: EOD received! Left = "0" So the issue for you is why does the connection get broken ? Perhaps your local squid cache closes the connection immediately when it is redirected ? Anyhow, this bug shows up in kdewebkit because it will not do the redirect when it gets and error message for the request it made. What it should do, to work like khtml, is ignore errors on redirection. That might fix kwebkitpart/rekonq working correctly for you, but it does not solve your actual problem of why you get broken connections in the first place...
SVN commit 1217274 by adawit: Disregard all errors received on valid redirects. Fixes BR# 263817 Improve debug message when receiving errors. CCBUG:263817 M +10 -5 accessmanagerreply_p.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1217274
I doubt the above fix will make it into the 4.6.0 release, but it will definitely be in the next minor point release 4.6.1.