Bug 242589

Fixed in KDE 4.5. There was a cookie handling related issue that has now been fixed in the KIO <=> QNetworkAccessManager integration classes. Thanks for the report.

The bug has NOT been fixed in KDE 4.5. I'm using KDE 4.5.2 (Kubuntu 10.10) and observing this very problem. The page renders just fine using Chrome and Konqueror (KHTML backend).

(In reply to comment #2)
> The bug has NOT been fixed in KDE 4.5. I'm using KDE 4.5.2 (Kubuntu 10.10) and
> observing this very problem. The page renders just fine using Chrome and
> Konqueror (KHTML backend).

You do understand that the kwebkitpart and khtml backends are different things. If you have issues with khtml, you need to open a ticket against that component (konqueror/khtml). This works fine in kwebkitpart which was what this report was all about...

(In reply to comment #3)
> (In reply to comment #2)
> > The bug has NOT been fixed in KDE 4.5. I'm using KDE 4.5.2 (Kubuntu 10.10) and
> > observing this very problem. The page renders just fine using Chrome and
> > Konqueror (KHTML backend).
> 
> You do understand that the kwebkitpart and khtml backends are different things.
> If you have issues with khtml, you need to open a ticket against that component
> (konqueror/khtml). This works fine in kwebkitpart which was what this report
> was all about...

Sorry, you didn't get what I meant. Google calendar doesn't load properly in Rekonq although it does in Konqueror using the KHTML backend and in Chrome. I was merely emphasizing that the issue appears to be with webkitkde. Apologies for the confusion.

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > The bug has NOT been fixed in KDE 4.5. I'm using KDE 4.5.2 (Kubuntu 10.10) and
> > > observing this very problem. The page renders just fine using Chrome and
> > > Konqueror (KHTML backend).
> > 
> > You do understand that the kwebkitpart and khtml backends are different things.
> > If you have issues with khtml, you need to open a ticket against that component
> > (konqueror/khtml). This works fine in kwebkitpart which was what this report
> > was all about...
> 
> Sorry, you didn't get what I meant. Google calendar doesn't load properly in
> Rekonq although it does in Konqueror using the KHTML backend and in Chrome. I
> was merely emphasizing that the issue appears to be with webkitkde. Apologies
> for the confusion.

Ooops. It is actually me that misread your comment. Sorry... 

Anyhow Google calendar works fine here with Konqueror + kwebkitpart. And since kwebkitpart and Rekonq use the same library (libkdewebkit), if there is a problem a rendering problem in one, it should show up in the other as well. 

Can you please specify the steps to follow to duplicate the issue ? I attempted to do certain things like creating/modifying and deleting events and it all worked perfectly fine for me. BTW, what version of Qt does Kubuntu 10.10 come with ? Perhaps that is the issue...

Sometimes it works, sometimes it doesn't, but most of the time it doesn't. (I get the error "Sorry..." as mentioned in the bug report.) E.g. I just loaded up gcal, it worked, so I've reloaded it three times now and none of them have loaded properly. I just installed kpart-webkit (ver. 0.9) and the same thing happens in Konqueror using webkit as backend.

My Qt version is 4.7.0., KDE 4.5.2 and Rekonq 0.6.1.

I just noticed that the calendar becomes accessible by switching the view mode from, e.g., Month to Week.

Can you please install the Arora browser and see if it is afflicted by
the same problem ? We need to determine whether or not this is a KDE
specific issue (i.e. QtWebKit/KDE integration) or an upstream one...

On Tue, Oct 19, 2010 at 12:22 PM,  <niburu1@hotmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=242589
>
>
>
>
>
> --- Comment #7 from  <niburu1 hotmail com>  2010-10-19 18:22:24 ---
> I just noticed that the calendar becomes accessible by switching the view mode
> from, e.g., Month to Week.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> WebKit-devel mailing list
> WebKit-devel@kde.org
> https://mail.kde.org/mailman/listinfo/webkit-devel
>

BTW, I still cannot reproduce this issue, but I am using the latest development version of QtWebKit, not the one included with Qt 4.7.0...

Version 0.10.2 of Arora loads google calendar just fine. The problem seems to be KDE-specific.

I cannot duplicate this problem here on my system (ArchLinux). Can you check to see if there are any errors being spitted out into a ~/.xsession-errors file, i.e. if there is one on your system ? Also can you locate a file called "https.protocol" on your system and see what the "maxInstancesPerHost" and "maxInstances" properties are set to ?

There's nothing in my ~/.xsession-errors file that mentions rekonq. I dug around but couldn't find the any https.protocol file. Any idea where it might be stored, e.g., in Kubuntu 10.10?

You can use the locate command to find it on your system: "locate
https.protocol". It should more than likely be under the
/usr/share/kde4/services/ folder...

On Thu, Oct 21, 2010 at 8:57 AM,  <niburu1@hotmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=242589
>
>
>
>
>
> --- Comment #12 from  <niburu1 hotmail com>  2010-10-21 14:57:13 ---
> There's nothing in my ~/.xsession-errors file that mentions rekonq. I dug
> around but couldn't find the any https.protocol file. Any idea where it might
> be stored, e.g., in Kubuntu 10.10?
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> WebKit-devel mailing list
> WebKit-devel@kde.org
> https://mail.kde.org/mailman/listinfo/webkit-devel
>

Thanks. There's no mention of "maxInstancesPerHost" or
"maxInstances". My file includes all and only the following:

[Protocol]
exec=kio_http
protocol=https
input=none
output=filesystem
reading=true
defaultMimetype=application/octet-stream
determineMimetypeFromExtension=false
Icon=www
config=http
DocPath=kioslave/https.html
Class=:internet

Well, there is your problem... No clue why your distro decided to
remove them and if they did not, how those values came to be missing
from your .protocol files, but you need to add them back. Here are the
stock protocol files shipped with the latest stable KDE release:

http://websvn.kde.org/branches/KDE/4.5/kdelibs/kioslave/http/http.protocol?view=markup
http://websvn.kde.org/branches/KDE/4.5/kdelibs/kioslave/http/https.protocol?view=markup
http://websvn.kde.org/branches/KDE/4.5/kdelibs/kioslave/ftp/ftp.protocol?view=markup
http://websvn.kde.org/branches/KDE/4.5/kdelibs/kioslave/file/file.protocol?view=markup

FYI, if the "maxInstances" and "maxInstancesPerHost" properties are
missing from these protocol files, the default value used will be 1!
That means at maximum you can only have one http protocol instance to
handle all HTTP requests! The same goes for all the other protocol
files that do not contain these properties. The per host property is
only applicable to protocols that connect to remote hosts and it used
to limit the number of ioslave instances allowed to service requests
to a given host.

Anyhow, add those two properties back and run the "kbuidsyscoca4"
command or log out of your current session and log back in. If your
issue is then fixed, which I suspect it will, then you need to report
this problem to your distribution...

On Thu, Oct 21, 2010 at 2:04 PM,  <niburu1@hotmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=242589
>
>
>
>
>
> --- Comment #14 from  <niburu1 hotmail com>  2010-10-21 20:04:14 ---
> Thanks. There's no mention of "maxInstancesPerHost" or
> "maxInstances". My file includes all and only the following:
>
> [Protocol]
> exec=kio_http
> protocol=https
> input=none
> output=filesystem
> reading=true
> defaultMimetype=application/octet-stream
> determineMimetypeFromExtension=false
> Icon=www
> config=http
> DocPath=kioslave/https.html
> Class=:internet
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> WebKit-devel mailing list
> WebKit-devel@kde.org
> https://mail.kde.org/mailman/listinfo/webkit-devel
>

Thanks for you help. I replaced all my protocol files with the ones you linked-to and unfortunately it had no effect: Rekonq and Konqueror + webkit still don't load google calendar correctly. This is upon rebooting after having made the changes.

(In reply to comment #16)
> Thanks for you help. I replaced all my protocol files with the ones you
> linked-to and unfortunately it had no effect: Rekonq and Konqueror + webkit
> still don't load google calendar correctly. This is upon rebooting after having
> made the changes.

There is one more thing you might want to try for kwebkitpart...


Find a file named $HOME/.kde/share/config/kioslaverc or $HOME/.kde/share/config/kio_httprc and add the following property at the top, i.e. global section:

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

Log back out and log back in and see if things work okay now with google calendar... If that does not help, then I have no idea why the site does not work for you so you might want to report the problem upstream to kubuntu's bug database referencing this ticket...

I am almost sure this is also caused by the caching bug in kio_http. Can you please disable caching and see if the problem goes away ?

Marking this as duplicate of bug# 256104. Most certainly that is the cause of this issue since similar incidents reported with other sites were also caused by the caching bug...

*** This bug has been marked as a duplicate of bug 256104 ***

Clearing and disabling cache appears to have worked. I've not encountered the problem again since. What I want to know now is what I've sacrified (e.g. performance?) by disabling caching.

(In reply to comment #20)
> Clearing and disabling cache appears to have worked. I've not encountered the
> problem again since. What I want to know now is what I've sacrified (e.g.
> performance?) by disabling caching.

Disabling caching is a temporary workaround until all the bugs are worked out in kio_http. That is why this bug report has been marked duplicate of 256104. Disabling the cache will of course have some performance cost to you in terms of always having to download the resources from the server...

*** Bug 263534 has been marked as a duplicate of this bug. ***