Bug 231932

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...

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?

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...

(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).

(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...

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.

(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...

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...

(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.

(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.

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

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

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

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