Bug 192851 - Space differences between GTK and Mac ports in tests
Summary: Space differences between GTK and Mac ports in tests
Status: RESOLVED DUPLICATE of bug 192750
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-19 06:10 PST by Alicia Boya García
Modified: 2018-12-19 06:55 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alicia Boya García 2018-12-19 06:10:32 PST
Many tests have failures due to small space differences. For instance, LayoutTests/animations/lineheight-animation.html fails in GTK since r184829, where a space was removed. Apparently the space was not being generated (anymore) in the Mac backend, but it still is in the GTK port: in effect, by editing the expectations, the test become green for Mac and at the same time become red in GTK.

Excerpt of LayoutTests/animations/lineheight-animation.html:

This test performs an animation of the line-height property. It tests whether or not we are properly getting the font-size.
<div id="box">
Here is some text. Here is some text. [...]
</div>

Output Mac: This test performs an animation of the line-height property. It tests whether or not we are properly getting the font-size.Here is some text. Here is some text. [...]
Output GTK: This test performs an animation of the line-height property. It tests whether or not we are properly getting the font-size. Here is some text. Here is some text. [...]

This makes me wonder: Should the space be there? What causes platform variations?

Can these be harmonized? I hope we don't need to duplicate (and update accordingly) expectations for each platform with the space variation forever.
Comment 1 Michael Catanzaro 2018-12-19 06:13:08 PST
Can you post links to image diffs?
Comment 2 Alicia Boya García 2018-12-19 06:27:45 PST
That's not the issue here. In fact, after more experimentation I've found this is due to differences in how different ports (and browsers!) implement innerText with absolute positioned elements differently.

Here is a testcase:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <title>innerText cross-platform differences</title>
  <style type="text/css" media="screen">
    #box {
        position: absolute;
    }
    </style>
</head>
<body>
Hello
<div id="box">
CSS
</div>
<script>
  document.body.innerText = document.body.innerText;
</script>
</body>
</html>

WebKitGTK:

Hello CSS

WebKit iOS (Safari):

HelloCSS

Firefox:

Hello
CSS

Google Chrome:

Hello CSS
Comment 3 Emilio Cobos Álvarez (:emilio) 2018-12-19 06:36:12 PST
I think this is a WebKit bug. Gecko is right on this one:

https://html.spec.whatwg.org/#the-innertext-idl-attribute says:

> If node's used value of 'display' is block-level or 'table-caption', then append 1 (a required line break count) at the beginning and end of items. [CSSDISPLAY]

In fact it's explicitly mentioned:

> Floats and absolutely-positioned elements fall into this category.
Comment 4 Emilio Cobos Álvarez (:emilio) 2018-12-19 06:42:56 PST
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=916540 for the relevant chromium issue.
Comment 5 Carlos Garcia Campos 2018-12-19 06:55:33 PST

*** This bug has been marked as a duplicate of bug 192750 ***