Determine why simple test cases have different render tree dumps on iOS and macOS 
https://bugs.webkit.org/show_bug.cgi?id=222362
Summary Determine why simple test cases have different render tree dumps on iOS and m...
Sam Weinig
Reported 2021-02-24 08:48:55 PST
In https://bugs.webkit.org/show_bug.cgi?id=222114, I added very simple render tree dumping tests (one replaced renderer, no text other than whitespace) that have different results on iOS and macOS. It would be good to figure out why these are different and see if we can fix those differences.
Attachments
Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2021-03-03 08:49:13 PST
<rdar://problem/74986434>
zalan
Comment 2 2021-03-04 17:13:35 PST
default font used by the test case: iOS: TimesNewRomanPSMT ascent: 14.675px adjusted to 15px descent: 4px line gap: 0.679688px adjusted to 1px macOS: Times-Roman ascent: 12px adjusted to 14px descent: 4px line gap: 0px These values make the line-spacing 20px on iOS while 18px on macOS. <div>text content</div> The height of the <div> is computed as (ascent + (line-spacing - ascent)) which produces a 18px tall box (18px for the glyphs + 0px gap) on macOS while a 20px tall box (19px for the glyphs + 1px gap) on iOS (2px taller!). But the test case does not have any text content! <!DOCTYPE> puts the document in standards mode. In standards mode the line is always stretched by the font metrics. e.g. <div style="outline: 1px solid green "><img style="background-color: red; width: 10px; height: 10px;"></div> -> the outline hugs the <img> box <!DOCTYPE html><div style="outline: 1px solid green "><img style="background-color: red; width: 10px; height: 10px;"></div> -> the outline does not hug the <img> box anymore as the line box is also stretched by the default font's line-spacing. In the test case the replaced content sits on the baseline and is taller than the default font's ascent. The computed "ascent" of the line is the replaced box's height (margin box) (let's say 20px). The computed "descent" value (line-spacing - ascent) is 5px on iOS while 4px on macOS (this includes the line gap). Line height is ascent + descent which makes the line 25px tall on iOS while 24px tall on iOS. This line height is then turned into the height of the containing block (body in this case). TLDR The (default)font used by the test case makes the line 2px taller on iOS than on macOS in general while with the replaced test case the diff is 1px due to the line gap. Avoid this problem by using consistent fonts such as AHEM.
Sam Weinig
Comment 3 2021-03-05 10:23:05 PST
I think the burden of knowing this seems too high for tests and we should work out how to make the default behavior of tests no fall into this. One idea is to check in fonts for various default font families for the test infrastructure to use. In the majority of cases I would guess using a standardized font would be appropriate, and for the few tests that want to test the system they happen to be running on, have some outlet to disable the checked in version.
Darin Adler
Comment 4 2021-03-05 14:49:43 PST
Sam, I think I agree with you, and I have a few words to say about why: Back when we first created layout tests, we decided that the default font would be the same as the default font (or the "default default font") in the Safari web browser. A critical goal was to have all the tests work both in web browsers and in the test framework, and the idea was to have them work as close to the same as possible between those two environments. I don’t think that goal is nearly as important any more. It’s more important that tests run in a repeatable environment without unnecessary platform-specific differences. Many tests will still run happily in the web browser. Using consistent fonts would be great, even if that means adding font loading machinery to the test runner tools. It might also be helpful if it was easy to make those available in the web browser for someone working on tests, to make it easier to successfully run tests in the browser. Maybe the fonts would match ones on macOS but not iOS, since running tests in the browser on iOS is probably less important.
Note You need to log in before you can comment on or make changes to this bug.