Version: unspecified (using KDE 4.5.2) OS: Linux The following website doesn't display correctly with kwebkitpart: https://vlebb.leeds.ac.uk/webapps/portal/frameset.jsp Tried with rekonq and konqueror + kwebkitpart. With other webkit-based (arora and chromium) browsers the website works correctly. I can't manage to compile kwebkitpart from svn because of a build error, otherwise I would have also tried with that version. Hope you can confirm and solve the bug. Thanks for all your hard and great work. Reproducible: Always Steps to Reproduce: Just open the website. Actual Results: The website is not displayed correctly. Expected Results: The website is displayed correctly.
(In reply to comment #0) > Version: unspecified (using KDE 4.5.2) > OS: Linux > > The following website doesn't display correctly with kwebkitpart: > https://vlebb.leeds.ac.uk/webapps/portal/frameset.jsp Cannot not reproduce... Can you please post a screenshot of the problem or describe how it is exactly not working ? This site renders exactly as it does in Arora and Chromium for me. My distro too is ArchLinux and I tested the site with both the current version of QtWebKit from git and the one that came with Qt 4.7 (v QtWebKit 2.0) with kdelibs from trunk... > Tried with rekonq and konqueror + kwebkitpart. > With other webkit-based (arora and chromium) browsers the website works > correctly. Did not try rekonq, but konqueror + kwebkitpart works fine here... > I can't manage to compile kwebkitpart from svn because of a build error, > otherwise I would have also tried with that version. For KDE 4.5 you need to check out the stable version from the repo listed below. The version in trunk requires kdelibs from trunk.... http://websvn.kde.org/branches/stable/extragear-kde4/base/kwebkitpart/ There is practically no difference between the version above and the one from trunk since none of the changes in the trunk have nothing to do with rendering sites... > Hope you can confirm and solve the bug. > Thanks for all your hard and great work. Thanks for taking the time to report issue to make kwebkitpart better...
Created attachment 53169 [details] Tarball containing the screenshots and the errors
Ok, I posted a tarball which contains four screenshots and two "error logs" that are occasionally displayed by rekonq instead of the real page. In fact, loading the page does not always lead to the same results! For example, the first time I loaded the website today, it was working correctly! Than I refreshed the page and I was displayed an "error message" instead of the real page (files: error.log, screenshot1.png)! Then I refreshed again and I was displayed the page with some missing images (?) at the top (screenshot2.png). At the next refresh I was also displayed an icon of missing image on the left (screenshot3.png). After another refresh I got another error (slightly different from the first one, that seems truncated at the beginning) (error2.log). Finally, after some additional refreshes, the big image on the left was displayed correctly (screenshot4.png), but refreshing again would again produce some random results. What do you think? Maybe I wasn't clear, but the website is working correctly for me as well with Arora and Chromium! Actually, I have kdelibs from trunk too (and the rest of kde as well), but kwebkitpart does not compile, complaining about KParts::SelectorInterface::QueryMethod not being declared and QueryMethods not naming a type...
(In reply to comment #3) > Ok, I posted a tarball which contains four screenshots and two "error logs" > that are occasionally displayed by rekonq instead of the real page. In fact, > loading the page does not always lead to the same results! > For example, the first time I loaded the website today, it was working > correctly! Then there is something else going on... I can definitely not reproduce this issue. See the attached screenshot. You might want to check and see if there are any KIO realted warnings or error messages in your ~/.xsession-errors file. > Than I refreshed the page and I was displayed an "error message" instead of the > real page (files: error.log, screenshot1.png)! Then I refreshed again and I was > displayed the page with some missing images (?) at the top (screenshot2.png). > At the next refresh I was also displayed an icon of missing image on the left > (screenshot3.png). After another refresh I got another error (slightly > different from the first one, that seems truncated at the beginning) > (error2.log). Finally, after some additional refreshes, the big image on the > left was displayed correctly (screenshot4.png), but refreshing again would > again produce some random results. Well to me this seems to be those images are not being retrieved... That is mostly likely the result of KIO not working properly... > What do you think? > > Maybe I wasn't clear, but the website is working correctly for me as well with > Arora and Chromium! Hmm... I never questioned it did not. All I said was that it works equally well for me in konqueror+kwebkitpart as it does in Arora and Chromium. That is all. > Actually, I have kdelibs from trunk too (and the rest of kde as well), but > kwebkitpart does not compile, complaining about > KParts::SelectorInterface::QueryMethod not being declared and QueryMethods > not naming a type... No, you do not have kdelibs from trunk if you are getting that compile error message. Do you by any chance have multiple versions of KDE installed side by side ? If so then are you sure all your enviornment variables and set ups are properly done ? Anyhow, I am unable to reproduce the problem. I have posted the screenshot of konqueror + kwebkitpart taken on my ArchLinux box with QtWebKit from Qt 4.7...
Created attachment 53180 [details] screenshot of site from konqueror+kwebkitpart
In my ~/.xsession-errors i have many messages from kio that say the same thing: klauncher(6097)/kio (KLauncher): SlavePool: No communication with slave. Could this be the problem? To not be in doubt about relating this problem to the fact that I had multiple versions of KDE installed, I removed my custom installation and I tried with Arch Linux's stock KDE 4.5.3, but the problem was still there. Then I tried adding the Arch Linux repository "kde-snapshots" and installed the kde packages from there (version 4.5.74svn1193262-1), which also included kwebkitpart-svn (same svn revision), and tried again, but the problem was still present. The last thing I tried was creating a new user, thinking that there could have been a problem with my configuration files, but I was wrong, and the website wasn't still displaying correctly. Any clues? Thanks for your help.
(In reply to comment #6) > In my ~/.xsession-errors i have many messages from kio that say the same thing: > klauncher(6097)/kio (KLauncher): SlavePool: No communication with slave. > > Could this be the problem? Nope. That is a normal debug message that is printed out when an ioslave is killed after it finishes doing its job. Actually it needs to be commented out since it is highly annoying. :) > To not be in doubt about relating this problem to the fact that I had multiple > versions of KDE installed, I removed my custom installation and I tried with > Arch Linux's stock KDE 4.5.3, but the problem was still there. Then I tried > adding the Arch Linux repository "kde-snapshots" and installed the kde packages > from there (version 4.5.74svn1193262-1), which also included kwebkitpart-svn > (same svn revision), and tried again, but the problem was still present. The > last thing I tried was creating a new user, thinking that there could have been > a problem with my configuration files, but I was wrong, and the website wasn't > still displaying correctly. > > Any clues? Well creating a new user would properly not help your case since the libraries are probably installed in a shared location, right ? What you might want to try out, if you have not already done so, is to check whether or not multiple versions the same the kdewebkit library are not in your path: slocate kdewebkit.so kwebkit.so kwebkitpart.so kdewebkit.so is the one that provides QtWebKit/KDE integration and the other two are the ones that provides the kpart integration. If there are multiple versions, delete the older ones and try again. Also you might want to clear KIO http's cache (ALT+F2 and type 'cache') if it is enabled. > > Thanks for your help.
> Well creating a new user would properly not help your case since the libraries > are probably installed in a shared location, right ? What you might want to try > out, if you have not already done so, is to check whether or not multiple > versions the same the kdewebkit library are not in your path: > > slocate kdewebkit.so kwebkit.so kwebkitpart.so I didn't check, but now I did and I have only one version of each library installed. > Also you might want to clear KIO http's cache (ALT+F2 and type 'cache') if it > is enabled. That did it! But just for the first time the page was loaded. So I disabled the cache completely and now it works! I can very well leave the settings as they are, but it would be nice to have cache again :) I'm not sure what to do now, should I open a bug elsewhere? Thanks!
(In reply to comment #8) > > Well creating a new user would properly not help your case since the libraries > > are probably installed in a shared location, right ? What you might want to try > > out, if you have not already done so, is to check whether or not multiple > > versions the same the kdewebkit library are not in your path: > > > > slocate kdewebkit.so kwebkit.so kwebkitpart.so > > I didn't check, but now I did and I have only one version of each library > installed. > > > Also you might want to clear KIO http's cache (ALT+F2 and type 'cache') if it > > is enabled. > > That did it! But just for the first time the page was loaded. So I disabled the > cache completely and now it works! I can very well leave the settings as they > are, but it would be nice to have cache again :) > I'm not sure what to do now, should I open a bug elsewhere? Nope. This report needs to just be switch to KIO http. I just tested with both konqueror + kwebkitpart and konqueror + khtml and I can duplicate the problem when caching is enabled.
*** Bug 257129 has been marked as a duplicate of this bug. ***
*** Bug 257053 has been marked as a duplicate of this bug. ***
The same problem stands for webdav kioslave, but unlike the http kioslave, you cannot remove the caching for webdav kioslave (or at least I didn't find how to do it..)
(In reply to comment #12) > The same problem stands for webdav kioslave, but unlike the http kioslave, you > cannot remove the caching for webdav kioslave (or at least I didn't find how to > do it..) The webdav and http kioslaves are one and the same. All webdav requests are processed by the http kioslave. There is no such thing as webdav ioslaves because webdav is simply an extension of the HTTP protocol. Anyhow, none of the webdav related function in kio_http make conditional server requests because all of them set the caching policy to CC_Reload everytime. As such, without the header that was received from kio_http[1], it would be hard to diagnose the problem. [1] You can provide the header generated by kio_http, by simply activating the kio_http debug area (7103) from the kdebugdialog application...
Here are the logs, but I have already seen that with wireshark: --------8<-----------8<------------8<--------8<-------8<----------- kio_http(15149) HTTPProtocol::sendQuery: ============ Sending Header: kio_http(15149) HTTPProtocol::sendQuery: "GET /users/p/pv/pviceic/www/Angry-PC-User.gif HTTP/1.1" kio_http(15149) HTTPProtocol::sendQuery: "Host: documents.epfl.ch" kio_http(15149) HTTPProtocol::sendQuery: "Connection: Keep-Alive" kio_http(15149) HTTPProtocol::sendQuery: "User-Agent: Mozilla/5.0 (compatible; Konqueror/4.4; Linux) KHTML/4.4.4 (like Gecko) SUSE" kio_http(15149) HTTPProtocol::sendQuery: "If-None-Match: "996439-1059099"" kio_http(15149) HTTPProtocol::sendQuery: "Accept: text/html, image/jpeg;q=0.9, image/png;q=0.9, text/*;q=0.9, image/*;q=0.9, */*;q=0.8" kio_http(15149) HTTPProtocol::sendQuery: "Accept-Encoding: x-gzip, x-deflate, gzip, deflate" kio_http(15149) HTTPProtocol::sendQuery: "Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5" kio_http(15149) HTTPProtocol::sendQuery: "Accept-Language: fr, en-US, en" kio_http(15149) HTTPProtocol::sendQuery: "Cookie: __utmz=33657086.1288698299.22.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=site%3Aepfl.ch%20r%C3%A9glement%20salles%20de%20r%C3%A9union; style=small; __utma=33657086.809761187.1285051829.1288884935.1289835435.26; xyc_XythosGroupDigest1=EAF5957BCA152E87565C0050EE274F8E030F9032; XythosSessionID1=[B@bb604a--1705682855; JSESSIONID=AF8425F052AE788817CB7F4FECF2FAB5" kio_http(15149) HTTPProtocol::readResponseHeader: ============ Received Status Response: kio_http(15149) HTTPProtocol::readResponseHeader: "HTTP/1.1 304 Not Modified --------8<-----------8<------------8<--------8<-------8<----------- The caching is emnabled. If I replace webdavs with https, no conditional get is issued.
I wanted to say that the caching is disabled..
(In reply to comment #15) > I wanted to say that the caching is disabled.. Ahhh... I do not see a webdav request in the log you posted... The caching issue with kio_http is already a known issue for which there will be a fix coming shortly. It is for the webdav issue you later reported that I asked for the debug output...
The output i have posted is the result of the execution of : konqueror webdavs://documents.epfl.ch/users/p/pv/pviceic/www/Angry-PC-User.gif The execution of konqueror https://documents.epfl.ch/users/p/pv/pviceic/www/Angry-PC-User.gif doesn't generate the If-None-Match header because I have disabled the caching. That make me think that when using webdavs, the caching is still enabled.
Here is the complete log where you can see the PROPFIND (RFC2518) request and then the faulty GET request: ---------8<--------------8<---------8<--------------8<------------- kio_http(17592) HTTPProtocol::sendQuery: ============ Sending Header: kio_http(17592) HTTPProtocol::sendQuery: "PROPFIND /users/p/pv/pviceic/www/Angry-PC-User.gif HTTP/1.1" kio_http(17592) HTTPProtocol::sendQuery: "Host: documents.epfl.ch" kio_http(17592) HTTPProtocol::sendQuery: "Connection: Keep-Alive" kio_http(17592) HTTPProtocol::sendQuery: "User-Agent: Mozilla/5.0 (compatible; Konqueror/4.4; Linux) KHTML/4.4.4 (like Gecko) SUSE" kio_http(17592) HTTPProtocol::sendQuery: "Pragma: no-cache" kio_http(17592) HTTPProtocol::sendQuery: "Cache-control: no-cache" kio_http(17592) HTTPProtocol::sendQuery: "Accept: text/html, image/jpeg;q=0.9, image/png;q=0.9, text/*;q=0.9, image/*;q=0.9, */*;q=0.8" kio_http(17592) HTTPProtocol::sendQuery: "Accept-Encoding: x-gzip, x-deflate, gzip, deflate" kio_http(17592) HTTPProtocol::sendQuery: "Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5" kio_http(17592) HTTPProtocol::sendQuery: "Accept-Language: fr, en-US, en" kio_http(17592) HTTPProtocol::sendQuery: "Cookie: __utmz=33657086.1288698299.22.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=site%3Aepfl.ch%20r%C3%A9glement%20salles%20de%20r%C3%A9union; style=small; __utma=33657086.809761187.1285051829.1288884935.1289835435.26; JSESSIONID=6A61EC69D11E09EAFA6B9F95431CCFB9" kio_http(17592) HTTPProtocol::sendQuery: "Depth: 0" kio_http(17592) HTTPProtocol::sendQuery: "Content-Type: text/xml; charset=utf-8" kio_http(17592) HTTPProtocol::readResponseHeader: ============ Received Status Response: kio_http(17592) HTTPProtocol::readResponseHeader: "HTTP/1.1 207 Multi-Status " kio_http(17592) HTTPProtocol::sendQuery: ============ Sending Header: kio_http(17592) HTTPProtocol::sendQuery: "GET /users/p/pv/pviceic/www/Angry-PC-User.gif HTTP/1.1" kio_http(17592) HTTPProtocol::sendQuery: "Host: documents.epfl.ch" kio_http(17592) HTTPProtocol::sendQuery: "Connection: Keep-Alive" kio_http(17592) HTTPProtocol::sendQuery: "User-Agent: Mozilla/5.0 (compatible; Konqueror/4.4; Linux) KHTML/4.4.4 (like Gecko) SUSE" kio_http(17592) HTTPProtocol::sendQuery: "If-None-Match: "996439-1059099"" kio_http(17592) HTTPProtocol::sendQuery: "Accept: text/html, image/jpeg;q=0.9, image/png;q=0.9, text/*;q=0.9, image/*;q=0.9, */*;q=0.8" kio_http(17592) HTTPProtocol::sendQuery: "Accept-Encoding: x-gzip, x-deflate, gzip, deflate" kio_http(17592) HTTPProtocol::sendQuery: "Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5" kio_http(17592) HTTPProtocol::sendQuery: "Accept-Language: fr, en-US, en" kio_http(17592) HTTPProtocol::sendQuery: "Cookie: __utmz=33657086.1288698299.22.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=site%3Aepfl.ch%20r%C3%A9glement%20salles%20de%20r%C3%A9union; style=small; __utma=33657086.809761187.1285051829.1288884935.1289835435.26; JSESSIONID=6A61EC69D11E09EAFA6B9F95431CCFB9" kio_http(17592) HTTPProtocol::readResponseHeader: ============ Received Status Response: kio_http(17592) HTTPProtocol::readResponseHeader: "HTTP/1.1 304 Not Modified ---------8<--------------8<---------8<--------------8<-------------
I have noticed that in http.cpp (davGeneric method), m_request.cacheTag.policy is indeed set to CC_Reload. However, GET request is not a webdav request but a plain HTTP 1.0 request. On the other side, in the method get(), the cache policy is based on data parsed from the (I suposse) request header. "Cache-control: no-cache" doesn't seem to match any proposition in KIO::parseCacheControl, so it defaults to CC_Verify..
(In reply to comment #19) > I have noticed that in http.cpp (davGeneric method), m_request.cacheTag.policy > is indeed set to CC_Reload. However, GET request is not a webdav request but a > plain HTTP 1.0 request. > > On the other side, in the method get(), the cache policy is based on data > parsed from the (I suposse) request header. "Cache-control: no-cache" doesn't > seem to match any proposition in KIO::parseCacheControl, so it defaults to > CC_Verify.. Ah yes... I forgot that webdav can do a GET request to retrieve the content. :( The whole caching problem will be fixed shortly ; so please wait for that then... I already have a patch that I am testing right now.
*** Bug 242589 has been marked as a duplicate of this bug. ***
*** Bug 249172 has been marked as a duplicate of this bug. ***
Is this bug still not resolved ? I mean, webdav kioslave is uselles without proper handling of cached files. Could you just force the reload as you do for the plain http get ? Bypass all this buggy cache handling ?
(In reply to comment #23) > Is this bug still not resolved ? I mean, webdav kioslave is uselles without > proper handling of cached files. Could you just force the reload as you do for > the plain http get ? Bypass all this buggy cache handling ? This should be fixed in KDE 4.6. At least all of the links provided above work for me. FYI, the commit of this fix is http://websvn.kde.org/?view=revision&revision=1199136 I will leave the ticket open until one of you tests the latest RC release or the final release of KDE 4.6...
Cool, thanks! But will someone backport this few lines to kde 4.4? I mean, even the upcoming OpenSuSE 11.4 doesn't plan to go with KDE 4.6 .. Le vendredi 14 janvier 2011 16.38:35, Dawit Alemayehu a écrit : > https://bugs.kde.org/show_bug.cgi?id=256104 > > > Dawit Alemayehu <adawit@kde.org> changed: > > What |Removed |Added > --------------------------------------------------------------------------- > - Version Fixed In| |4.6 > > > > > --- Comment #24 from Dawit Alemayehu <adawit kde org> 2011-01-14 16:38:32 > --- (In reply to comment #23) > > > Is this bug still not resolved ? I mean, webdav kioslave is uselles > > without proper handling of cached files. Could you just force the reload > > as you do for the plain http get ? Bypass all this buggy cache handling > > ? > > This should be fixed in KDE 4.6. At least all of the links provided above > work for me. FYI, the commit of this fix is > http://websvn.kde.org/?view=revision&revision=1199136 > I will leave the ticket open until one of you tests the latest RC release > or the final release of KDE 4.6...
SVN commit 1214418 by adawit: Backport the fix for BR# 256104. CCBUG:256104 M +9 -7 http.cpp M +1 -1 http.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1214418
Uhm, unfortunately I think that this isn't completely solved yet, because sometimes the web page still gets rendered incorrectly, with KDE 4.6.41 (4.7 >= 20110106), even though it happens much, much less frequently now (almost never).
(In reply to comment #27) > Uhm, unfortunately I think that this isn't completely solved yet, because > sometimes the web page still gets rendered incorrectly, with KDE 4.6.41 (4.7 >= > 20110106), even though it happens much, much less frequently now (almost > never). Is that the very same page you provided in the original report or other pages after you login ? Also did you clear your cache and try it ?
(In reply to comment #28) > Is that the very same page you provided in the original report or other pages > after you login ? Also did you clear your cache and try it ? Yes, it was the same page. When it didn't work I just clicked on reload and the page worked again.
Mmm, I just got the error again, and I discovered that I can reproduce it easily this time, it's not as random as it was before: when the page is not shown correctly and I press reload, it's loaded correctly, and when it's loaded correctly and I press reload, it doesn't work anymore (except for the first time I go to the page: if it is loaded correctly, I have to press reload twice for it to stop working). This is with KDE 4.6.41 (4.7 >= 20110106), rekonq 0.6.50, and kwebkitpart-svn 1192463. The page is still the same: https://vlebb.leeds.ac.uk/webapps/portal/frameset.jsp
(In reply to comment #30) > Mmm, I just got the error again, and I discovered that I can reproduce it > easily this time, it's not as random as it was before: when the page is not > shown correctly and I press reload, it's loaded correctly, and when it's loaded > correctly and I press reload, it doesn't work anymore (except for the first > time I go to the page: if it is loaded correctly, I have to press reload twice > for it to stop working). This is with KDE 4.6.41 (4.7 >= 20110106), rekonq > 0.6.50, and kwebkitpart-svn 1192463. > The page is still the same: > https://vlebb.leeds.ac.uk/webapps/portal/frameset.jsp Hmm... I did as you stated and visited the site and reloaded it 6 times. The page was correctly shown each and every time. I guess we have to keep an eye on this for now. There are still some issues in kio_http caching code that needs fixing, but I do not have time for those right now.
Is this issue still present in the latest versions of KDE, v4.9 or higher for you ? I cannot reproduce the problems mentioned in comment #30 using Konqueror + kwebkitpart with or without enabling caching.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!