Bug 149703 – [GTK] DOM operations could behave unexpectedly with certain fonts or font sizes

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Tomas Popela]

Created attachment 262248 [details]
test-case

There is a bug in ?freetype/cairo/webkit? that for some fonts and font sizes the DOM operations does not behave as it should. The cause is well document in https://bugs.webkit.org/show_bug.cgi?id=102374 .

As it is mentioned in https://bugs.webkit.org/show_bug.cgi?id=102374#c44 and https://bugs.webkit.org/show_bug.cgi?id=102374#c45 things should be fixed for freetype >= 2.4.6, but the truth is that the change in freetype was reverted later ( as you can read in http://lists.nongnu.org/archive/html/freetype-devel/2013-01/msg00070.html ).

I'm attaching a test case that will fail on trunk as well as on WK1 (it the background should be red and caret should be on the end of the first line instead of second line). Actually this is what we are using in Evolution and it is broken for someone ( https://bugzilla.gnome.org/show_bug.cgi?id=749712 ).

I think that there are two ways of solving it. Do it like EFL: basically enabling subpixel layout (applying http://trac.webkit.org/changeset/140111 ) or what I've tried on current master is to apply the proposed patch from https://bugs.webkit.org/show_bug.cgi?id=102374#c44 . With the latter the test case succeeded.

What are your opinions? Especially Martin's as he was quite active around it.

[Martin Robinson]

I think it is worth testing subpixel layout. Do you have a sense for how many test results change?

[Tomas Popela]

(In reply to comment #0)
> I think that there are two ways of solving it. Do it like EFL: basically
> enabling subpixel layout (applying http://trac.webkit.org/changeset/140111 )

OK, so I was wrong as I thought that enabling subpixel layout fixes it. I compiled EFL port and they are also affected. I will ask some EFL developer to confirm it.

[Csaba Osztrogonác]

I checked it on EFL, the background is red 
and the caret is at the end of the first line.

[Dario Lesca]

I use Gnome Evolution 3.16.5 on Fedora 22, and I have found many undu/redo bugs into html email, especially when I reply to and the message have indent text.

This is my rpm situation:
[lesca@dodo ~]$ rpm -qa |grep -i webki
webkitgtk4-2.8.5-2.fc22.x86_64
webkitgtk-2.4.9-2.fc22.x86_64
kdelibs-webkit-4.14.12-1.fc22.x86_64
qtwebkit-devel-2.3.4-6.fc22.x86_64
webkitgtk3-2.4.9-2.fc22.x86_64
qtwebkit-2.3.4-6.fc22.x86_64
pywebkitgtk-1.1.8-9.fc22.x86_64
qt5-qtwebkit-5.5.0-4.fc22.x86_64

I must report all problem found in this bug?
 
Thanks

[Tomas Popela]

(In reply to comment #4)
> I use Gnome Evolution 3.16.5 on Fedora 22, and I have found many undu/redo
> bugs into html email, especially when I reply to and the message have indent
> text.
> 
> This is my rpm situation:
> [lesca@dodo ~]$ rpm -qa |grep -i webki
> webkitgtk4-2.8.5-2.fc22.x86_64
> webkitgtk-2.4.9-2.fc22.x86_64
> kdelibs-webkit-4.14.12-1.fc22.x86_64
> qtwebkit-devel-2.3.4-6.fc22.x86_64
> webkitgtk3-2.4.9-2.fc22.x86_64
> qtwebkit-2.3.4-6.fc22.x86_64
> pywebkitgtk-1.1.8-9.fc22.x86_64
> qt5-qtwebkit-5.5.0-4.fc22.x86_64
> 
> I must report all problem found in this bug?
>  
> Thanks

No, report these bugs agains Evolution component in Gnome bugzilla. The consequences of this bug in Evolution are already mentioned in comment #0 and there is no need to repeat them again.

[Tomas Popela]

Fixed with bug 176351 (requiring freetype 2.8)

[Tomas Popela]

Reopen this bug as I want to add a new layout test for this bug.

[Tomas Popela]

Created attachment 320250 [details]
Patch

[Michael Catanzaro]

Comment on attachment 320250 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=320250&action=review

It's not often that people contribute regression tests except when trying to get a functional change into WebKit. Thanks! Also good to see the test passes the Apple EWS bots on the first try.

> LayoutTests/fast/dom/Document/CaretRangeFromPoint/restore-selection-from-point.html:56
> +    <div style="width: 72ch; word-wrap: normal;" >12</div>
> +    <div style="width: 72ch; word-wrap: normal;" >34<span id="selection-start"></span><span id="selection-end"></span></div>

The 12 and 34 are arbitrary, right? That's a bit confusing.

[Tomas Popela]

(In reply to Michael Catanzaro from comment #9)
> > LayoutTests/fast/dom/Document/CaretRangeFromPoint/restore-selection-from-point.html:56
> > +    <div style="width: 72ch; word-wrap: normal;" >12</div>
> > +    <div style="width: 72ch; word-wrap: normal;" >34<span id="selection-start"></span><span id="selection-end"></span></div>
> 
> The 12 and 34 are arbitrary, right? That's a bit confusing.

Yes, they are.. Before landing I will rework it so it takes the current content of the second line and it does not hardcode the content.

[Tomas Popela]

Committed r221843: <http://trac.webkit.org/changeset/221843>