[Webkit-unassigned] [Bug 134597] Convert fast/css/text-overflow-ellipsis* layout tests to reftests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=134597





--- Comment #23 from Mario Sanchez Prada <mario at webkit.org>  2014-07-24 06:27:56 PST ---
It seems that part of the reason why these tests are failing here only in the mac is because of the calls to drawSkipInkUnderline() functions, which are not being called in WebKitGTK+ (because of the ENABLE(CSS3_TEXT_DECORATION_SKIP_INK) guard).

When that function is called, translateIntersectionPointsToSkipInkBoundaries() is called too where it seems that "way too many" dashes (and the gaps in the middle) are being returned as the result DashArray. Reason for that seems to be that is not taking into consideration the fact that the whole text might be ellipsized, and therefore adding tuples of coordinates definining those gaps which are out of the range defined by the visible part of the text is wrong, causing the underline to show up shorter than what it actually is if there's a single character later on the line requiring a "ink skip".

The following experiment "fixes" some cases of this weird behaviour, even though it does not seem correct (we would probably need to properly consider text direction and things like that):

--- a/Source/WebCore/rendering/InlineTextBox.cpp
+++ b/Source/WebCore/rendering/InlineTextBox.cpp
@@ -80,8 +80,11 @@ static DashArray translateIntersectionPointsToSkipInkBoundaries(const DashArray&

     // Step 1: Make pairs so we can sort based on range starting-point. We dilate the ranges in this step as well.
     Vector<std::pair<float, float>> tuples;
-    for (auto i = intersections.begin(); i != intersections.end(); i++, i++)
+    for (auto i = intersections.begin(); i != intersections.end(); i++, i++) {
+        if (*i <= -totalWidth || *i >= totalWidth)
+            continue;
         tuples.append(std::make_pair(*i - dilationAmount, *(i + 1) + dilationAmount));
+    }

Unfortunately, I don't have much time anymore this week and I'll be away for a while after it, so I can't keep devoting time to this issue (which happens to show up in the Mac only, btw), so I'm posting this here in the hope that someone with a better understanding of this part can take a look and see whether it makes sense or not.

PS: drawLineForText() works perfectly fine, the problem is with drawSkipInkUnderline() because translateIntersectionPointsToSkipInkBoundaries() returns gaps not belonging to the visible (not wrapped) test, which causes that weird effect.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.