1860124 - Firefox fails size-adjust-unicode-range-system-fallback.html , but only on wpt.fyi harness

Status: RESOLVED MOVED

(Core :: Layout: Text and Fonts, defect)

Description

[Daniel Holbert [:dholbert]]

(this came to my attention via https://github.com/web-platform-tests/interop/issues/542 )

wpt.fyi shows us failing this test:
https://wpt.fyi/results/css/css-fonts/size-adjust-unicode-range-system-fallback.html
Live test on wpt.live:
http://wpt.live/css/css-fonts/size-adjust-unicode-range-system-fallback.html

This was added just a few weeks ago in bug 1854181 (commit).

However, we don't appear to fail the test in our own test harness. We don't have any .ini annotation for it. So something must be different between our TreeHerder CI vs. the wpt.fyi CI that's causing us to fail it upstream.

Also, two other interesting facts:

• Our failure screenshots on wpt.fyi show us displaying Tofu fallback-glyph (3042), with the testcase rendering the glyph as being quite large, vs. the reference case rendering it as small.
• Safari's failure screenshot shows them rendering the actual glyph, but with the same sizing difference (testcase much larger than reference case).

Comment 1

[Daniel Holbert [:dholbert]]

When I run the test locally (on Linux), it passes, and I see the correct (I think?) glyph showing up (it looks like https://www.fileformat.info/info/unicode/char/3042/index.htm ), at the correct small size, rendered with Noto Sans CJK.

Comment 2

[Daniel Holbert [:dholbert]]

Aha! If I remove the two packages that can provide this glyph for me...
sudo apt remove fonts-noto-cjk fonts-droid-fallback
...then I see the failure, both in the harness and when loading the testcase directly. The testcase renders with a giant 3042 tofu box.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase to explore behavior a bit

Here's a testcase based on the upstream one, but now using a different character U+10FFFE which is more guaranteed to trigger a tofu-box.

(This testcase sort-of expects you to have Ahem installed, but it falls back to the wpt.live-hosted-version too, if you don't have it.)

In this testcase, I added another @font-face block with unicode-range: U+0061; which represents the a character, and I used the three-times-as-large size-adjust: 3000%; for that one, and I added an a character for good measure.

Despite that, we "only" use the size-adjust: 1000% from the other font-face rule, which is associated with the space character (unicode-range: U+0020).

So it seems like we're treating the size-adjust of the space character specially as determining the size-adjust for tofu-boxes. jfkthame, do you know if that's intentional? FWIW WebKit seems to be doing the same.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

So it seems like we're treating the size-adjust of the space character specially as determining the size-adjust for tofu-boxes.

Possibly this has some relation to the "first available font" definition at https://drafts.csswg.org/css-fonts-4/#first-available-font , which is based on whether or not the unicode-range includes the space character, U+0020.

Comment 5

[Daniel Holbert [:dholbert]]

Tofu-handling-aside, we probably want to fix things such that either:
(1) the wpt.fyi test runners have a font available (that Firefox can find) which has a glyph for the U+3042 codepoint, so that we can render the expected glyph instead of Tofu
...or:
(2) The test uses some other character instead of U+3042 that we can reliably guarantee will be present in some fallback font on wpt.fyi (but is still triggering whatever system-font-fallback codepath that the test is expecting to trigger in order to continue to serve as a regression-test for the Chrome bug that it was added for
...or:
(3) The test should perhaps be removed or moved to be .tentative if there's no way to fix it.

jgraham, do you know enough about our wpt.fyi test-runners to know if we can guarantee (1)? It seems like a low bar to expect those test runners to have some font that can render Japanese characters like U+3042.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

jgraham, do you know enough about our wpt.fyi test-runners to know if we can guarantee (1)? It seems like a low bar to expect those test runners to have some font that can render Japanese characters like U+3042.

(ni for that^ question. See comment 2 for two font packages that are available (and installed-by-default, I think?) on Ubuntu which both provide this glyph. Perhaps we can ensure that our wpt.fyi test runners have equivalent font packages?)

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

So it seems like we're treating the size-adjust of the space character specially as determining the size-adjust for tofu-boxes. jfkthame, do you know if that's intentional? FWIW WebKit seems to be doing the same.

Yeah, I think this makes sense. When the character isn't supported in any of the available fonts, and so we fall back to drawing a tofu box, we'll treat this as though belonging to the "first available font" as defined by CSS. The resource with a unicode-range that doesn't include <space> is not eligible to be "first available", and isn't used to determine the size of the tofu (or, I think, to resolve normal line height).

Comment 8

[James Graham [:jgraham]]

https://github.com/web-platform-tests/wpt/pull/42730 seems to fix this locally (installing the noto fonts package into the docker image).

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to James Graham [:jgraham] from comment #8)

https://github.com/web-platform-tests/wpt/pull/42730 seems to fix this locally (installing the noto fonts package into the docker image).

Awesome. That is probably the real fix for this issue.

Given comment 7, it seems there's not really a Gecko bug here, and our test-failing-behavior is in fact correct, given the constraints of the fonts that have been available in the WPT environment. Let's resolve this as MOVED to https://github.com/web-platform-tests/wpt/pull/42730 , and we can consider this fixed by that.