Bug 192434 – [GTK] fast/inline/inline-content-with-float-and-margin.html is 1 pixel off

• Status: NEW
• Component: WebKitGTK

[Alicia Boya García]

fast/inline/inline-content-with-float-and-margin.html

Failing since r238487-238613

--- /home/slave/webkitgtk/gtk-linux-64-debug-tests/build/layout-test-results/fast/inline/inline-content-with-float-and-margin-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-debug-tests/build/layout-test-results/fast/inline/inline-content-with-float-and-margin-actual.txt
@@ -5,55 +5,55 @@
     RenderBody {BODY} at (8,8) size 784x584
 layer at (8,8) size 102x52 clip at (9,9) size 100x50
   RenderBlock {DIV} at (0,0) size 102x52 [border: (1px solid #008000)]
-    RenderText {#text} at (29,1) size 66x14
-      text run at (29,1) width 66: "foobar foobar"
+    RenderText {#text} at (29,1) size 65x14
+      text run at (29,1) width 65: "foobar foobar"
     RenderBlock (floating) {SPAN} at (11,11) size 8x22 [border: (1px solid #0000FF)]
       RenderText {#text} at (1,1) size 6x14
         text run at (1,1) width 6: "2"
-    RenderText {#text} at (29,15) size 66x14
-      text run at (29,15) width 66: "foobar foobar"
+    RenderText {#text} at (29,16) size 65x14
+      text run at (29,16) width 65: "foobar foobar"
 layer at (8,60) size 102x52 clip at (9,61) size 100x50
   RenderBlock {DIV} at (0,52) size 102x52 [border: (1px solid #008000)]
-    RenderText {#text} at (19,1) size 66x14
-      text run at (19,1) width 66: "foobar foobar"
+    RenderText {#text} at (19,1) size 65x14
+      text run at (19,1) width 65: "foobar foobar"
     RenderBlock (floating) {SPAN} at (11,1) size 8x22 [border: (1px solid #0000FF)]

[Carlos Garcia Campos]

This can be just rebaselined.

[Alicia Boya García]

Why are sizes now 1 pixel shorter?

[Michael Catanzaro]

(In reply to Alicia Boya García from comment #0)
> Failing since r238487-238613

With an impossible range like that, who can say?

It's one pixel and we have thousands of more important bugs. Best just rebaseline it.

[Carlos Garcia Campos]

We are now running tests with complex text always enabled, and we updated all deps that affect text rendering freetype, fontconfig, harfbuzz, cairo and icu. Any of those could have caused this, I rebaselined a lot of tests in both cases, I guess I missed this one.

[Alicia Boya García]

(In reply to Michael Catanzaro from comment #3)
> (In reply to Alicia Boya García from comment #0)
> > Failing since r238487-238613
> 
> With an impossible range like that, who can say?

Yeah... but that's the shortest range I get from the bots. All those revisions were covered by a single GTK build & test; were they down for weeks or something?