Bug 231932 - http://webchat.freenode.net/ renders a blank page in kwebkitpart
Summary: http://webchat.freenode.net/ renders a blank page in kwebkitpart
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Unclassified
Component: kdewebkit (show other bugs)
Version: SVN
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Dawit Alemayehu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-23 19:38 UTC by Jakob Lehmann
Modified: 2012-01-27 13:20 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.7.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakob Lehmann 2010-03-23 19:38:39 UTC
Version:            (using KDE 4.4.1)
OS:                Linux
Installed from:    Ubuntu Packages

The Freenode Webchat at http://webchat.freenode.net/ renders a blank page in kwebkit, tried it with konqueror and rekonq in KDE SC 4.4.1 under Ubuntu Lucid Lynx.
Comment 1 Dawit Alemayehu 2010-04-12 06:06:57 UTC
I know exactly why this happens and the bug has nothing to do with what you think... First to fix the problem add the line below to the global section of your $KDEHOME/share/config/kioslaverc file and restart konqueror:

UserAgent=Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/528.1 (KHTML, like Gecko) konqueror/4.4.1 Safari/528

This will ensure that by default, i.e. before the request ever reaches the kwebkitpart, Konqueror is sending out the proper user agent. Otherwise, the default KHTML string will be sent out, which obviously is not supported by this site. Anywho, I was able to duplicate your problem by commenting out the above line in my kioslaverc file. With it present I get the correct rendering ; so this is not really a bug in kwebkitpart. It is an issue that needs to be addressed elsewhere so that the proper user-agent string is sent...
Comment 2 Jakob Lehmann 2010-04-12 06:20:25 UTC
Ok, thanks for clearing that up.
Though this bug might be invalid for kwebkit, it is still valid for something else... I'll mark it a kio bug, do you agree with this?
Comment 3 Dawit Alemayehu 2010-04-12 12:53:09 UTC
On Monday, April 12, 2010 00:20:26 Jakob Lehmann wrote:
> https://bugs.kde.org/show_bug.cgi?id=231932
> 
> 
> Jakob Lehmann <jamano910@googlemail.com> changed:
> 
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
> - Status|RESOLVED                    |REOPENED
>          Resolution|INVALID                     |
> 
> 
> 
> 
> --- Comment #2 from Jakob Lehmann <jamano910 googlemail com>  2010-04-12
> 06:20:25 --- Ok, thanks for clearing that up.
> Though this bug might be invalid for kwebkit, it is still valid for
> something else... I'll mark it a kio bug, do you agree with this?

IMO it should actually be reported against the application, which in this case 
is Konqueror. The reason is because every time you type an HTTP address into 
Konqueror's location bar, it always wants to identify the resource type of the 
entered url so that it can embed or use the right KPart. Unfortunately the 
only way it can do that is to go ahead and request the resource in order to  
obtain its mime-type, e.g. text/html. That particular act is the cause of this 
problem, which makes the fix a little more complicated... Anyways, I personally 
think the bug should be  reported against Konqueror and handled appropriately 
from there. It is also something that is already on my TODO list, but if and 
when I will get to it is up in the air...
Comment 4 Jakob Lehmann 2010-05-22 07:17:14 UTC
(In reply to comment #3)
> IMO it should actually be reported against the application, which in this case 
> is Konqueror. The reason is because every time you type an HTTP address into 
> Konqueror's location bar, it always wants to identify the resource type of the 
> entered url so that it can embed or use the right KPart. Unfortunately the 
> only way it can do that is to go ahead and request the resource in order to  
> obtain its mime-type, e.g. text/html. That particular act is the cause of this 
> problem, which makes the fix a little more complicated... Anyways, I personally 
> think the bug should be  reported against Konqueror and handled appropriately 
> from there. It is also something that is already on my TODO list, but if and 
> when I will get to it is up in the air...

Well... If it would just affect konqueror I'd agree with that, but it affects other browsers that use kwebkit as well, too, such as rekonq. Can a bug be marked for more than one application? Otherwise it may be a kwebkit bug again in the end, though it is not it's fault (neither it is rekonqs).
Comment 5 Dawit Alemayehu 2010-05-23 17:53:58 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > IMO it should actually be reported against the application, which in this case 
> > is Konqueror. The reason is because every time you type an HTTP address into 
> > Konqueror's location bar, it always wants to identify the resource type of the 
> > entered url so that it can embed or use the right KPart. Unfortunately the 
> > only way it can do that is to go ahead and request the resource in order to  
> > obtain its mime-type, e.g. text/html. That particular act is the cause of this 
> > problem, which makes the fix a little more complicated... Anyways, I personally 
> > think the bug should be  reported against Konqueror and handled appropriately 
> > from there. It is also something that is already on my TODO list, but if and 
> > when I will get to it is up in the air...
> 
> Well... If it would just affect konqueror I'd agree with that, but it affects
> other browsers that use kwebkit as well, too, such as rekonq. Can a bug be
> marked for more than one application? Otherwise it may be a kwebkit bug again
> in the end, though it is not it's fault (neither it is rekonqs).

ehh... no it should not. The reason is simple. This problem occurs because of how Konqueror works, using KParts. In order to properly handle the request you type into its location bar, Konqueror first has to find out its mime-type. That way it can load the appropriate KPart that was configured to handle the specific mime-type. In other words, the original request you type into Konqueror's location is always handled by itself using KIO. Unfortunately, that means the default user-agent string built into KIO (KProtocolManager to be exact) will be used.

As such unless the other kdewebkit based applications are like Konqueror, i.e. use KParts, and do the same thing Konqueror does, i.e. try to determine mime-type before loading the appropriate part to handle the request, then they are not inflicted by this issue at all. I know for a fact that reKonq is not KParts based and as such it should not be affected with this bug at all...
Comment 6 Jakob Lehmann 2010-05-23 19:28:32 UTC
This bug is reproducable with arora, rekonq and konqueror with webkitpart.
I talked to someone on #rekonq who said it might be a qt bug that is fixed in 4.7, do you use qt 4.7? Furthermore I wasnt able to fix this bug in rekonq/konqueror with webkit with your workaround.
I use kubuntu lucid with qt 4.6.
Comment 7 Dawit Alemayehu 2010-05-23 20:03:09 UTC
(In reply to comment #6)
> This bug is reproducable with arora, rekonq and konqueror with webkitpart.
> I talked to someone on #rekonq who said it might be a qt bug that is fixed in
> 4.7, do you use qt 4.7? 

Yes, I am running what will become QtWebKit 2.0 (will be included in Qt 4.7).

> Furthermore I wasnt able to fix this bug in rekonq/konqueror with webkit with 
> your workaround. I use kubuntu lucid with qt 4.6.

Then you are indeed encountering a bug in the Qt 4.6 version of QtWebKit. None the less even with QtWebKit 2.0, I was able to reproduce your problem because of the issue I mentioned above. I gues in this case you get hit by double bugs if you use Konqueror+kwebkipart...
Comment 8 Dawit Alemayehu 2011-05-25 22:50:14 UTC
Funny how the link now seems to work fine with khtml, but shows a blank page with kdewebkit based browsers. IOW, the porblem has completely flipped. Will investigate...
Comment 9 Jakob Lehmann 2011-05-27 13:51:56 UTC
(In reply to comment #8)
> Funny how the link now seems to work fine with khtml, but shows a blank page
> with kdewebkit based browsers. IOW, the porblem has completely flipped. Will
> investigate...

For me it works with both khtml and rekonq, this is with qt 4.7.2 and KDE 4.6.2.
Comment 10 Dawit Alemayehu 2011-05-27 16:18:52 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Funny how the link now seems to work fine with khtml, but shows a blank page
> > with kdewebkit based browsers. IOW, the porblem has completely flipped. Will
> > investigate...
> 
> For me it works with both khtml and rekonq, this is with qt 4.7.2 and KDE
> 4.6.2.

Yes, it used to work fine before for me as well. However, in the upcoming KDE 4.7 version of kdewebkit, there seems to be a regression that causes this page not to render as blank and therefore needs to be addressed before 4.7 final.
Comment 11 Dawit Alemayehu 2011-07-08 17:26:34 UTC
Git commit c3e213d910afb7a819a2434f153215c4dbca99e6 by Dawit Alemayehu.
Committed on 08/07/2011 at 16:58.
Pushed by adawit into branch 'KDE/4.7'.

Added support for synchronous requests.

This is needed to address the fact that QtWebKit from v2.2 forwards no longer
creates its own event loop to handle such requests. Instead it expects QNAM, or
any reimplementation, to deal with it on its behalf. Credit goes to Pierre
Rossi for discovering this issue.

BUG: 231932
FIXED-IN: 4.7.0
REVIEW: 101876

M  +18   -0    kio/kio/accessmanager.cpp     

http://commits.kde.org/kdelibs/c3e213d910afb7a819a2434f153215c4dbca99e6
Comment 12 Dawit Alemayehu 2011-07-08 17:29:30 UTC
Git commit 9544fbfbd757053b4a982b0800f59f87a78bf686 by Dawit Alemayehu.
Committed on 08/07/2011 at 16:58.
Pushed by adawit into branch 'master'.

Added support for synchronous requests.

This is needed to address the fact that QtWebKit from v2.2 forwards no longer
creates its own event loop to handle such requests. Instead it expects QNAM, or
any reimplementation, to deal with it on its behalf. Credit goes to Pierre
Rossi for discovering this issue.

BUG: 231932
FIXED-IN: 4.7.0
REVIEW: 101876

(cherry picked from commit c3e213d910afb7a819a2434f153215c4dbca99e6)

M  +17   -0    kio/kio/accessmanager.cpp     

http://commits.kde.org/kdelibs/9544fbfbd757053b4a982b0800f59f87a78bf686
Comment 13 Dawit Alemayehu 2012-01-17 21:21:20 UTC
Git commit 462a06ea08d2ece143fe0daa59ceb8523ed0b763 by Dawit Alemayehu.
Committed on 17/01/2012 at 21:12.
Pushed by adawit into branch 'KDE/4.8'.

Avoid using a nested event loops for synchronous XMLHttpRequest by letting
Qt's networking code, which can block without a need for a local event loop,
deal with such requests.
Related: bug 287778
FIXED-IN: 4.8.0

M  +14   -12   kio/kio/accessmanager.cpp

http://commits.kde.org/kdelibs/462a06ea08d2ece143fe0daa59ceb8523ed0b763
Comment 14 Sebastian Trueg 2012-01-27 13:20:54 UTC
Git commit cbb00baee6fb8ff1af4f4b00786f3e2d132a3fbc by Sebastian Trueg, on behalf of Dawit Alemayehu.
Committed on 17/01/2012 at 21:12.
Pushed by trueg into branch 'KDE/4.8'.

Avoid using a nested event loops for synchronous XMLHttpRequest by letting
Qt's networking code, which can block without a need for a local event loop,
deal with such requests.
Related: bug 287778
FIXED-IN: 4.8.0

M  +14   -12   kio/kio/accessmanager.cpp

http://commits.kde.org/kdelibs/cbb00baee6fb8ff1af4f4b00786f3e2d132a3fbc