[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: KDE/kdelibs/kio/kio
From:       Dawit A <adawit () kde ! org>
Date:       2010-09-29 0:38:30
Message-ID: AANLkTinfu+vN=Uv7wjmd5htu=cb77WbNtAhhBdyYgap1 () mail ! gmail ! com
[Download RAW message or body]

On Tue, Sep 28, 2010 at 11:37 AM, David Faure <faure@kde.org> wrote:
> On Tuesday 28 September 2010, Dawit Alemayehu wrote:
>> +static QString defaultUserAgentFromPreferredService()
>> +{
>> +  QString agentStr;
>> +
>> +  // Check if the default COMPONENT contains a custom default UA string...
>> +  KService::Ptr service =
>> KMimeTypeTrader::self()->preferredService(QL1S("text/html"),
>> +                                                      QL1S("KParts/ReadOn
>> lyPart")); +  if (service && service->showInKDE())
>> +    agentStr = service->property(QL1S("X-KDE-Default-UserAgent-String"),
>> +                                 QVariant::String).toString();
>> +  return agentStr;
>> +}
>> +
>
> This actually goes wrong when using the View menu to switch between the two
> html renderers.

Right... I could not figure out how to solve that issue easily. It
should however be noted that an incorrect user-agent string will only
be sent when you type something into Konqueror's location bar.

> Why don't we simply add a KIO::setDefaultUserAgent(const QString&)
> and call it from the html engines before opening urls?

Because they are not the cause of the problem. Konqueror is! As you
alluded to, rendering engine components can easily set the user-agent
identifier through the "UserAgent" metadata to send the whatever
string they want. But that can only happen if and when the actual
network request originates from them. In fact, kdewebkit by default
provides KDE user-agent integration using KProtocolManager out of the
box (see kdewebkit/kwebpage.cpp).

The problem comes you type a url into Konqueror's location bar... In
that case Konqueror always opts to "stat" the url to discover its
mime-type so that it can call upon the proper kpart to handle the
request. That means that original request never reaches the part
itself, though it might reuse the same connection once Konqueror calls
upon it. That is the cause of bugs like this one:

https://bugs.kde.org/show_bug.cgi?id=198428

Additionally, the user-agent configuration dialog was not designed
with multiple html rendering components in mind ; so when you change
the default rendering engine it would still display the incorrect
user-agent string because it uses KProtocolManager as well.

> Yes it can still go wrong when khtmlpart and webkitpart are used at the very
> same time, but this is starting to be corner case ;)

Personally I think that the ability to change rendering engines on the
fly should just be removed since you have now added the ability to
switch the engines from the config dialog. There are more problematic
issues besides this one when switching back and forth between engines
like that. I am specifically talking about history navigation...

> I'm also thinking that preferredService might take a bit of time, in something
> called quite often. I tried to make the trader fast, but still.

That should not be much of an issue since the user-agent string gets
cached until there is a configuration change which should be  a rare
occurrence...

[prev in list] [next in list] [prev in thread] [next in thread]