Bug 291277

khtml renders test case nicely -> kdewebkit bug

(In reply to comment #1)
> khtml renders test case nicely -> kdewebkit bug

The attached test case renders exactly the same in both khtml and webkit browser engines for me. But that is with QtWebKit 2.2 which is what is included in Qt 4.8. Are you sure you tested this with the webkit browser engine ?

Created attachment 67709 [details]
webkit rendering screenshot

libQtWebKit4-4.8.0+2.2.0-8.1.i586 with KDE 4.7.97

I use kde 4.7.2 release 5 from openSuSE 12.1, libQtWebKit.so.4.9.0

Created attachment 67712 [details]
screenshot webkit rendering sample

And here is what I get here ; so this is either dependent on the default font used or something else because there should be no difference with this.

Do you get the same thing with both Konqueror + webkit and reKonq ? If it is just with Konqueror, do you have the latest version (1.2.0) kwebkitpart ?

Created attachment 67713 [details]
Rekonq ss

kwebkitpart-1.2.0git20111019-1.2.i586

same graphical result with rekonq 0.8.0-2.1.2;
kwebkitpart 1.2.0git20111019-1.2
strange enough, adding
    font-family: sans-serif;
to the CSS rules changes the font, although it's the same in the Settings:Web Browsing:Appearance||Fonts tab. Konqueror still does not render appropriately the justify rule.
Changes to the ||Stylesheets tabs, to another default stylesheet, only take effect at next starting up of Konqueror ([Apply] has no effect, neither has Reload after exiting Settings)

NEW TEST GIVES HINT:
Replacing all spaces by at least two spaces (tested space, \n, \t) makes rendering OK!
(tested both Konqueror and rekonq)

new test shows problem in whitespace inserting algorithm.

Starting from the situation in k.html,
+ create a line with much white space by replacing the space by an underscore in a few words;
+ measure the whitespace at the end of line
+ inserting one or more spaces after a word  shows that the rendering engine
    1. computes the white space to distribute
    2. divides this between the actual number of spaces
    3. augments only those spaces which has at least two \s characters

(In reply to comment #7)
> same graphical result with rekonq 0.8.0-2.1.2;
> kwebkitpart 1.2.0git20111019-1.2
> strange enough, adding
>     font-family: sans-serif;
> to the CSS rules changes the font, although it's the same in the Settings:Web
> Browsing:Appearance||Fonts tab. Konqueror still does not render appropriately
> the justify rule.
> Changes to the ||Stylesheets tabs, to another default stylesheet, only take
> effect at next starting up of Konqueror ([Apply] has no effect, neither has
> Reload after exiting Settings)

Well, I dunno what to tell you as I still cannot reproduce your problem here. I even tried the qtwebkit test program QtTestBrowser and the results I get in it, Konqueror + webkit, reKonq and Arora are all the same to me and the justification works just fine as shown in my screenshot. BTW, even if  I was able to reproduce it,  this would need to be reported upstream against QtWebKit since there is nothing we can do to fix this issue here. However, since I am unable to reproduce the problem, I won't suggest you report it upstream.

> NEW TEST GIVES HINT:
> Replacing all spaces by at least two spaces (tested space, \n, \t) makes
> rendering OK!
> (tested both Konqueror and rekonq)

Can you attach the sample file with those changes as well for reference.

Created attachment 67747 [details]
test files

Tommi Tervo uses
libQtWebKit4-4.8.0+2.2.0-8.1.i586 with KDE 4.7.97

Pol Briand uses
kde 4.7.2 release 5 from openSuSE 12.1, libQtWebKit4 4.7.4-2.2.0-2.1.2

~> uname -a
Linux linux-desk 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) i686 i686 i386 GNU/Linux

Created attachment 67818 [details]
test files and screen copy

RELATED PROBLEM
In a block element with text-align = justify, konqueror wrongly inserts space before an in-line block.

Updated to
libQtWebKit4 4.8.0+2.2.0-8.1 with still exactly same result

(In reply to comment #12)
> Created an attachment (id=67818) [details]
> test files and screen copy
> 
> RELATED PROBLEM
> In a block element with text-align = justify, konqueror wrongly inserts space
> before an in-line block.

Cannot reproduce that either. That means there is something else going on. Why do I not see the issue, but both of you do ? @Tommi do you use OpenSUSE too ? Is this a distro specific issue ? I am using ArchLinux.

(In reply to comment #14)

> Is this a distro specific issue ? I am using ArchLinux.

It seems that the issue is with Qt and SuSE; when I opt in [Konqueror -> menu -> Settings -> Configure Konqueror -> General -> default browser engine] for KHTML, rendering is OK.

I posted a report for the SuSE team
https://bugzilla.novell.com/show_bug.cgi?id=741400

and posted on a SuSE forum.

While the KHTML option suits my needs, I would readily contribute by investigating more, if only I knew how.

(In reply to comment #15)
> (In reply to comment #14)
> 
> > Is this a distro specific issue ? I am using ArchLinux.
> 
> It seems that the issue is with Qt and SuSE; when I opt in [Konqueror -> menu
> -> Settings -> Configure Konqueror -> General -> default browser engine] for
> KHTML, rendering is OK.

Hmm... That makes no sense. In kwebkitpart we read and use the font settings of KHTML. Whatever you set for khtml is used by kwebkitpart ; so rendering in one should produce almost similar results in another. Did you try to create a new account to see if the problem remains for a newly created account ?

(In reply to comment #16)
> Hmm... That makes no sense. In kwebkitpart we read and use the font settings of
> KHTML. Whatever you set for khtml is used by kwebkitpart ; so rendering in one
> should produce almost similar results in another.

I do not quite get the relationship between the font settings and the wrong insertion of white space. From a 'black box' perspective, with the webkit option Konqueror computes correctly the space to distribute -- so I'd say it has the fonts right -- but then fails do distribute effectively, so unless the document has at least two space-characters between words and there is no in-line element inside a word, it renders ugly.

> Did you try to create a new
> account to see if the problem remains for a newly created account ?

Yes. I tried this; unsurprisingly, I get the same: I detected this problem after a new install, so my account was newly created. Konqueror had the default webkit web engine option, and when I changed this, the rendering was all right.

(In reply to comment #17)
> (In reply to comment #16)
> > Hmm... That makes no sense. In kwebkitpart we read and use the font settings of
> > KHTML. Whatever you set for khtml is used by kwebkitpart ; so rendering in one
> > should produce almost similar results in another.
> 
> I do not quite get the relationship between the font settings and the wrong
> insertion of white space. From a 'black box' perspective, with the webkit
> option Konqueror computes correctly the space to distribute -- so I'd say it
> has the fonts right -- but then fails do distribute effectively, so unless the
> document has at least two space-characters between words and there is no
> in-line element inside a word, it renders ugly.

How exactly are you going to know the amount of spaces to add between words if you actually do not have the font metrics information ? That is why the font type and size, i.e. your fonts settings, and the justified text shown on the page are related to one another.

At least that is what I meant. This has to be a distribution specific issue. I cannot reproduce the problem with any of the test cases you provided so far.

> > Did you try to create a new
> > account to see if the problem remains for a newly created account ?
> 
> Yes. I tried this; unsurprisingly, I get the same: I detected this problem
> after a new install, so my account was newly created. Konqueror had the default
> webkit web engine option, and when I changed this, the rendering was all right.

Well I most definitely do not know what to tell you here. I have no idea what SUSE is doing, but with the stock KDE and QtWebKit, which is what I am using I cannot reproduce the issue.

(In reply to comment #7)
> same graphical result with rekonq 0.8.0-2.1.2;
> kwebkitpart 1.2.0git20111019-1.2
> strange enough, adding
>     font-family: sans-serif;
> to the CSS rules changes the font, although it's the same in the Settings:Web
> Browsing:Appearance||Fonts tab. Konqueror still does not render appropriately
> the justify rule.
> Changes to the ||Stylesheets tabs, to another default stylesheet, only take
> effect at next starting up of Konqueror ([Apply] has no effect, neither has
> Reload after exiting Settings)

This is an unrelated issue, but the style sheet configuration dialog is currently khtml specific only. Even though some of the changes you make will apply to the webkit engine, e.g. custom style sheet, the configuration dialog only shows you the changes as it applies to khtml. This slated to be fixed in 4.9.0.

> NEW TEST GIVES HINT:
> Replacing all spaces by at least two spaces (tested space, \n, \t) makes
> rendering OK!
> (tested both Konqueror and rekonq)

I do not have this problem at all using either rekonq or Konqueror or the Qt only based browser Arora.

(In reply to comment #18)

> How exactly are you going to know the amount of spaces to add between words if
> you actually do not have the font metrics information ? That is why the font
> type and size, i.e. your fonts settings, and the justified text shown on the
> page are related to one another.

I suppose webkit 1. If style.whitespace == normal, all white spaces are collapsed; 2. What's not whitespace makes up anonymous inline blocks of known width (webkit has the font metrics); 3. Sets as many inline blocks so as total width + (n-1) word spaces does not exceed line length (I can measure this dimension on the left-align version); 4. Distributes the leftover space between the in-line blocks (I can calculate the increment to every word space).

This observation led me to remark that those words that were separated by more than one space (i.e. one space and one line feed) were (approximately, I confess) correctly spaced in the failed rendering. So I tried to encode two spaces at all points, and the rendering was nearly OK. Note that I did not need to knows the details of font metrics, and that the rendering is good in left-aligned style shows that webkit does not get that font information wrong very much.

Git commit 0a2893eeb33175dbc7acd7df365f95d34d13d44d by Dawit Alemayehu.
Committed on 13/03/2012 at 14:00.
Pushed by adawit into branch 'master'.

Removed hard dependency on khtml by using the newly added JavaScript settings
from KParts::HtmlSettingsInterface.

Changed kcmcss to embed the default browser engine when previewing user defined
CSS settings.

M  +2    -2    konqueror/settings/konqhtml/CMakeLists.txt
M  +61   -51   konqueror/settings/konqhtml/css/kcmcss.cpp
M  +6    -5    konqueror/settings/konqhtml/css/kcmcss.h
M  +0    -1    konqueror/settings/konqhtml/generalopts.cpp
M  +11   -11   konqueror/settings/konqhtml/javaopts.cpp
M  +7    -6    konqueror/settings/konqhtml/jsopts.cpp
M  +22   -27   konqueror/settings/konqhtml/jspolicies.cpp
M  +19   -31   konqueror/settings/konqhtml/jspolicies.h

http://commits.kde.org/kde-baseapps/0a2893eeb33175dbc7acd7df365f95d34d13d44d

Is this problem still present in more recent version of your distro ? I am still unable to reproduce the issue.

On Monday, July 16, 2012 23:09:42 you wrote:
> https://bugs.kde.org/show_bug.cgi?id=291277
> 
> --- Comment #22 from Dawit Alemayehu <adawit@kde.org> ---
> Is this problem still present in more recent version of your distro ? I am
> still unable to reproduce the issue.

I still use the same version, following the old saying: if it's not broken, do 
not replace it.

Konqueror works about right for the use I have with KHTML and has the bug with 
Webkit.

(In reply to comment #23)
> On Monday, July 16, 2012 23:09:42 you wrote:
> > https://bugs.kde.org/show_bug.cgi?id=291277
> > 
> > --- Comment #22 from Dawit Alemayehu <adawit@kde.org> ---
> > Is this problem still present in more recent version of your distro ? I am
> > still unable to reproduce the issue.
> 
> I still use the same version, following the old saying: if it's not broken,
> do not replace it.
> 
> Konqueror works about right for the use I have with KHTML and has the bug
> with Webkit.

Ok. I see why I was not able to reproduce this problem. I was using a more recent version of QtWebKit than v2.2.0. If I downgrade to the "officially" released version of QtWebKit1, I can readily reproduce all the problems you listed here. 

The good news is that the bugs are already fixed upstream. The bad news is there will probably never be an official update released, e.g. v2.3.0, for QtWebKit1. The QtWebKit guys have moved on to QtWebKit2 and any future updates is going to depend on someone picking up the QtWebKit1 branch and maintaining it. There are some efforts towards that, but no concrete date on update releases at the moment. See the following post: http://adjamblog.wordpress.com/category/rekonq/ for more details on this issue.

Created attachment 72884 [details]
spacing problem

(In reply to comment #24)
> Ok. I see why I was not able to reproduce this problem. I was using a more
> recent version of QtWebKit than v2.2.0. If I downgrade to the "officially"
> released version of QtWebKit1, I can readily reproduce all the problems you
> listed here. 

Is there any way to use Konqueror with QtWebKit2? I'd like to, because there is one more problem I have. I'm not sure these problems are connected. Html for screenshot:
<html>
<style>
p {letter-spacing: -2px}
</style>
<body>
<p>any text (<span>123</span>)</p>
</body>
</html>

Should I open new bug for this?

(In reply to comment #25)
> Created attachment 72884 [details]
> spacing problem
> 
> (In reply to comment #24)
> > Ok. I see why I was not able to reproduce this problem. I was using a more
> > recent version of QtWebKit than v2.2.0. If I downgrade to the "officially"
> > released version of QtWebKit1, I can readily reproduce all the problems you
> > listed here. 
> 
> Is there any way to use Konqueror with QtWebKit2? 

Unfortunately the answer here is no. Not for the foreseeable future. The QtWebKit2 API is completely different than the QtWebKit1 API since it is based on WebKit2 and its split process model. Currently the API provided by QtWebKit2 does not allow it to be used as a browser engine rendering engine and is almost entirely designed to be used from QML.

> I'd like to, because there
> is one more problem I have. I'm not sure these problems are connected. Html
> for screenshot:
> <html>
> <style>
> p {letter-spacing: -2px}
> </style>
> <body>
> <p>any text (<span>123</span>)</p>
> </body>
> </html>
> 
> Should I open new bug for this?

It won't do any good for a couple of reasons. First it is obviously not a bug in kdewebkit itself. kdewebkit is nothing more than a thin wrapper around QtWebKit1 to allow use of KDE's frameworks such as KIO and KWallet. Second that bug is likely already fixed in upstream version of QtWebKit as well. Unfortunately, those changes did not make it into the version branched, tested and included with Qt 4.8. However, if you still want to report the bug, I suggest you follow the guides outlined at http://trac.webkit.org/wiki/QtWebKitBugs and report the bug there.

(In reply to comment #24)
> The good news is that the bugs are already fixed upstream. The bad news is
> there will probably never be an official update released, e.g. v2.3.0, for
> QtWebKit1. The QtWebKit guys have moved on to QtWebKit2 and any future
> updates is going to depend on someone picking up the QtWebKit1 branch and
> maintaining it. There are some efforts towards that, but no concrete date on
> update releases at the moment. See the following post:
> http://adjamblog.wordpress.com/category/rekonq/ for more details on this
> issue.

Strike the above comment. See http://lists.webkit.org/pipermail/webkit-qt/2012-August/003000.html.

This is an upstream issue that has already been fixed that has already been fixed in a future qtwebkit-2.3 branch [1]. When that version will be released is another topic altogether, 

[1] https://gitorious.org/+qtwebkit-developers/webkit/qtwebkit-23