Bug 289029 - rekonq shows HTML code instead of rendered page
Summary: rekonq shows HTML code instead of rendered page
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Unclassified
Component: general (show other bugs)
Version: 4.7
Platform: Archlinux Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Andrea Diamantini
URL:
Keywords:
: 286135 289586 293600 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-12-15 09:16 UTC by Giovanni Venturi
Modified: 2012-02-08 07:15 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
the NOT rendered page (119.37 KB, image/png)
2011-12-15 09:16 UTC, Giovanni Venturi
Details
g plus load fail (545.48 KB, image/png)
2011-12-26 10:18 UTC, Andrea Diamantini
Details
g plus load fail content (77.32 KB, text/plain)
2011-12-26 10:19 UTC, Andrea Diamantini
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Giovanni Venturi 2011-12-15 09:16:01 UTC
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
Comment 1 Andrea Diamantini 2011-12-16 21:04:40 UTC
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
Comment 2 Andrea Diamantini 2011-12-16 21:05:21 UTC
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
Comment 3 Andrea Diamantini 2011-12-23 17:59:24 UTC
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.
Comment 4 Dawit Alemayehu 2011-12-24 04:33:53 UTC
(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.
Comment 5 Andrea Diamantini 2011-12-24 06:22:30 UTC
(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.
Comment 6 Dawit Alemayehu 2011-12-24 07:27:54 UTC
(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 ?
Comment 7 Andrea Diamantini 2011-12-26 08:36:14 UTC
(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.
Comment 8 Andrea Diamantini 2011-12-26 10:18:10 UTC
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.
Comment 9 Andrea Diamantini 2011-12-26 10:18:57 UTC
Created attachment 67117 [details]
g plus load fail
Comment 10 Andrea Diamantini 2011-12-26 10:19:26 UTC
Created attachment 67118 [details]
g plus load fail content
Comment 11 Andrea Diamantini 2011-12-29 17:40:06 UTC
*** Bug 286135 has been marked as a duplicate of this bug. ***
Comment 12 Andrea Diamantini 2011-12-29 17:40:45 UTC
*** Bug 289586 has been marked as a duplicate of this bug. ***
Comment 13 Dawit Alemayehu 2011-12-29 21:29:30 UTC
(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 ?
Comment 14 Andrea Diamantini 2011-12-30 09:44:00 UTC
(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.
Comment 15 Andrea Diamantini 2012-01-15 10:29:05 UTC
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
Comment 16 Giovanni Venturi 2012-01-15 12:34:15 UTC
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!
Comment 17 Andrea Diamantini 2012-02-08 07:15:52 UTC
*** Bug 293600 has been marked as a duplicate of this bug. ***