Created attachment 66768 [details] the NOT rendered page Version: 0.8.1 (using KDE 4.7.3) OS: Linux After I logged into a GMail account I see HTML code insteal of the rendered page and it's not the first website that does this. Reproducible: Always Steps to Reproduce: log into the gmail account from rekonq from www.gmail.com Actual Results: it shows the HTML code page on https://accounts.google.com/ServiceLoginAuth Expected Results: an HTML rendered page. OS: Linux (i686) release 2.6.32.49-1-lts Compiler: gcc
Git commit 3e59ea5cab2a0972e1a618bed9b7f2de8025dbf9 by Andrea Diamantini. Committed on 16/12/2011 at 22:01. Pushed by adjam into branch 'master'. Do NOT search for (probably) non extant favicons also use KIO::copy instead of KIO::file_copy to delegate file management to KIO This should hopefully fix||workaround HTML code shown bug. Anyway, I cannot understand why KIO merges the two different jobs data together CCBUG: 289029 M +9 -4 src/iconmanager.cpp http://commits.kde.org/rekonq/3e59ea5cab2a0972e1a618bed9b7f2de8025dbf9
Git commit 3b6913c3b25021ba9e3687afad56d3907e642a65 by Andrea Diamantini. Committed on 16/12/2011 at 22:01. Pushed by adjam into branch 'Branches.0.8'. Do NOT search for (probably) non extant favicons also use KIO::copy instead of KIO::file_copy to delegate file management to KIO This should hopefully fix||workaround HTML code shown bug. Anyway, I cannot understand why KIO merges the two different jobs data together CCBUG: 289029 M +9 -4 src/iconmanager.cpp http://commits.kde.org/rekonq/3b6913c3b25021ba9e3687afad56d3907e642a65
After a bit of investigation, I decided to reopen and move this bug to KIO. This is the situation: I have (obviously) KIO calls in kdewebkit and some calls in other classes to retrieve eg. icons, download files, etc. Every time one of the kio call (coming from the other classes) fail, results are "mixed" in kdewebkit data, showing "modified" pages, as the one in this bug report.
(In reply to comment #3) > After a bit of investigation, I decided to reopen and move this bug to KIO. > This is the situation: I have (obviously) KIO calls in kdewebkit and some calls > in other classes to retrieve eg. icons, download files, etc. Every time one of > the kio call (coming from the other classes) fail, results are "mixed" in > kdewebkit data, showing "modified" pages, as the one in this bug report. Hmm... you completely lost me there. You are making direct KIO calls from reKonq and using kdewebkit of course ; so you are saying that if the KIO calls you make fails, you get the HTML source of the page ?? If so what is the error code you get back from KIO ? None of that makes any sense to me though and if there were such issues, I should encounter this problems in Konqueror as well.
(In reply to comment #4) > (In reply to comment #3) > > After a bit of investigation, I decided to reopen and move this bug to KIO. > > This is the situation: I have (obviously) KIO calls in kdewebkit and some calls > > in other classes to retrieve eg. icons, download files, etc. Every time one of > > the kio call (coming from the other classes) fail, results are "mixed" in > > kdewebkit data, showing "modified" pages, as the one in this bug report. > > Hmm... you completely lost me there. You are making direct KIO calls from > reKonq and using kdewebkit of course ; so you are saying that if the KIO calls > you make fails, you get the HTML source of the page ?? If so what is the error > code you get back from KIO ? None of that makes any sense to me though and if > there were such issues, I should encounter this problems in Konqueror as well. I admit my explanation is a bit "fantasious" :D What I'm experiencing is: while loading web pages, I have a class downloading icon. I'm using a KIO::file_copy(srcUrl, destUrl, -1, KIO::HideProgressInfo) there. Code in my IconManager class falls back to srcUrl = "http://" + 'url.host()' + "/favicon.ico" to eventually try downloading one. When srcUrl does not exist, the problem described here sometimes appear. I imagine that 'that sometimes' depends on who does before (site or icon request). You are probably not experiencing it in konqueror because it just relies on favicon kded module.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > After a bit of investigation, I decided to reopen and move this bug to KIO. > > > This is the situation: I have (obviously) KIO calls in kdewebkit and some calls > > > in other classes to retrieve eg. icons, download files, etc. Every time one of > > > the kio call (coming from the other classes) fail, results are "mixed" in > > > kdewebkit data, showing "modified" pages, as the one in this bug report. > > > > Hmm... you completely lost me there. You are making direct KIO calls from > > reKonq and using kdewebkit of course ; so you are saying that if the KIO calls > > you make fails, you get the HTML source of the page ?? If so what is the error > > code you get back from KIO ? None of that makes any sense to me though and if > > there were such issues, I should encounter this problems in Konqueror as well. > > I admit my explanation is a bit "fantasious" :D > What I'm experiencing is: while loading web pages, I have a class downloading > icon. I'm using a KIO::file_copy(srcUrl, destUrl, -1, KIO::HideProgressInfo) > there. Code in my IconManager class falls back to srcUrl = "http://" + > 'url.host()' + "/favicon.ico" to eventually try downloading one. > When srcUrl does not exist, the problem described here sometimes appear. I > imagine that 'that sometimes' depends on who does before (site or icon > request). Hmm... then I think I know what might be causing your problem! It is probably the put ioslave on hold for reuse functionality of the Scheduler where an ioslave is put on hold so that it can be handed over to another application for reuse. But that should not be happening under such circumstances at all! Can you please enable debug area 7006 to some output file and look for anything that says "ON HOLD" when you run into this problem ? Also what happens if you wait to download the favicon when you receive the loadFinished(...) signal instead ? > You are probably not experiencing it in konqueror because it just relies on > favicon kded module. That is correct. Is there any specificy reason why you are not doing the same thing ? Are you maintaining your own icons ?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > Hmm... then I think I know what might be causing your problem! It is probably > the put ioslave on hold for reuse functionality of the Scheduler where an > ioslave is put on hold so that it can be handed over to another application for > reuse. But that should not be happening under such circumstances at all! Can > you please enable debug area 7006 to some output file and look for anything > that says "ON HOLD" when you run into this problem ? Also what happens if you > wait to download the favicon when you receive the loadFinished(...) signal > instead ? Ok, doing this test. > > You are probably not experiencing it in konqueror because it just relies on > > favicon kded module. > > That is correct. Is there any specificy reason why you are not doing the same > thing ? Are you maintaining your own icons ? uhm... I think we started because we needed a way to download site icons without really loading the site.
No "ON HOLD" comments. I probably understood how I can reproduce it. It depends on the last job done in load. In fact the bug never happens on first load. When the favicon request is last on previous load, you reload page and bug appears. This way I could reproduce it on g+. I'm attaching here a screenshot of this + ALL the text shown in the page. This way you can notice it really is NOT the HTML code of the page, but (probably) one (or two) content requests mixed.
Created attachment 67117 [details] g plus load fail
Created attachment 67118 [details] g plus load fail content
*** Bug 286135 has been marked as a duplicate of this bug. ***
*** Bug 289586 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > No "ON HOLD" comments. I probably understood how I can reproduce it. It depends > on the last job done in load. In fact the bug never happens on first load. When > the favicon request is last on previous load, you reload page and bug appears. > This way I could reproduce it on g+. So the bug appears when you reload the page ? The output attachements do not show me anything except for the fact that the favicon was not found. This probably would end up send you back an error page. Because kio_http is by default configured to do that. I am not entirely sure if that is what you are encountering, but you could try setting the meta-data that prevents the sending of error page when you requests your favorite icons, e.g. job->addMetaData("errorPage", "false"); The other thing I noticed is the weird name you use for th favorite icon. why is it called "faviconr.ico" ? what is the "r" before the "." about ?
(In reply to comment #13) > > So the bug appears when you reload the page ? The output attachements do not > show me anything except for the fact that the favicon was not found. This > probably would end up send you back an error page. Because kio_http is by > default configured to do that. I am not entirely sure if that is what you are > encountering, but you could try setting the meta-data that prevents the sending > of error page when you requests your favorite icons, e.g. > job->addMetaData("errorPage", "false"); The bug appears when the last job done is a favicon failed load and the next page you load is from the same site. You can also click on an internal link. Thanks for errorPage metadata suggestion. Unfortunately, it doesn't fix the problem :( > The other thing I noticed is the weird name you use for th favorite icon. why > is it called "faviconr.ico" ? what is the "r" before the "." about ? From g+ source code: <link rel="shortcut icon" href="//ssl.gstatic.com/s2/oz/images/faviconr.ico"> Our IconManager start working on loadFinished, checks cache before and then page header to search for an "icon" or "shortcut icon" link header. At least it falls back to url.host() + "/favicon.ico". As said, problem appears when this srcUrl does not really exist.
Git commit 1efea8ed92f07e8a1156d87fa59f259e3b78bccd by Andrea Diamantini. Committed on 15/01/2012 at 11:15. Pushed by adjam into branch 'master'. Move icon manager download system to QNAM & Search also for favicon.ico files This seems to be the unique method to surely workaround this bug rekonq encounters when tries to load an unextant favicon with KIO (see ) M +1 -0 src/CMakeLists.txt A +110 -0 src/icondownloader.cpp [License: GPL (v2/3)] C +15 -32 src/icondownloader.h [from: src/iconmanager.h - 056% similarity] M +6 -68 src/iconmanager.cpp M +1 -5 src/iconmanager.h M +2 -2 src/sessionmanager.cpp M +1 -1 src/sessionmanager.h M +1 -1 src/webview.h http://commits.kde.org/rekonq/1efea8ed92f07e8a1156d87fa59f259e3b78bccd
Can you release reKonq 0.8.2 with this fix too? Yesterday I was using reKonq to buy a train ticket and after I payed I got the page ful of html code... I gone in panic!
*** Bug 293600 has been marked as a duplicate of this bug. ***