1982903 - wpt css/CSS2/selectors/first-letter-punctuation-{004|005|006}.xht fail on new android 14 emulator

Status: RESOLVED DUPLICATE of bug 1977236

(Core :: CSS Parsing and Computation, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

on a try push I have a few failures:
https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=fdea14904f15d8fe3a01e1277a1ad60054bf5e8e&test_paths=%2Fcss%2Fcss2%2Fselectors&selectedTaskRun=anr4nYzlRseXIeoG1NQOnw.0

looking at the reftest compare it appears we are not rendering the fonts/characters in the reference image.

this is for:
css/CSS2/selectors/first-letter-punctuation-004.xht
css/CSS2/selectors/first-letter-punctuation-005.xht

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

in fact there are 3 other tests with the same failure and reference image that isn't rendering:

• /css/css-counter-styles/tibetan/css3-counter-styles-155.html
• /css/css-counter-styles/tibetan/css3-counter-styles-156.html
• /css/css-counter-styles/tibetan/css3-counter-styles-157.html

Comment 2

[Timothy Nikkel (:tnikkel)]

Could it be an issue with async font loading? We have a pref that can disabled that that we use for tests sometimes.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

yes, all of these tests are solved with adding the gfx.font_rendering.fallback.async:false. since I am adding that (as part of bug 1977236) I will leave this bug open, but happy to see this closed if there is no other work to do here.

Comment 4

[Jonathan Kew [:jfkthame]]

Yeah, these all look like async-fallback issues.

I'll just close this as a dupe of bug 1977236 as it sounds like you're handling it over there.

Comment 5

[Jamie Nicol [:jnicol]]

We seem to ship with gfx.font_rendering.fallback.async = true. Could there be a real bug with this path on recent android versions that users could run in to? Or is this just a thing that sometimes we have to disable for tests?

Comment 6

[Timothy Nikkel (:tnikkel)]

I don't know too much about it, just that it is used to make tests pass. I would guess that for regular users we don't want to block showing text for too long on loading the correct font, but in tests we really want to wait for the correct font so that we take the snapshot using the correct font instead of the correct font loading after we have taken the snapshot. I'll let Jonathan weigh in though.

Comment 7

[Jonathan Kew [:jfkthame]]

Yeah, that's basically it. We may temporarily render the page without the proper fallback fonts, but that will automatically refresh as soon as the fonts are available. Disabling fallback.async means we will instead block rendering while waiting for the fonts, which is generally worse for users (slower page-load/rendering), but avoids the test capturing a temporary rendering with different (or missing) fonts.

In a bit more detail, what's going on is that when we need to find a fallback font, we iterate over the available fonts checking their character coverage. If there are fonts for which character map coverage has not yet been loaded in this session, this can be quite expensive, so rather than block layout while waiting for the font data to load, we'll just fire off a message (to the parent process) asking for the loading to happen, but the content process proceeds as if the font were unavailable, and may choose a different fallback (or, in the worst case, none at all -- resulting in a missing-glyph box), but at least the user gets to see the page.

Once the parent process has loaded the character coverage data, it'll notify the content process to do a reflow so that it will now find the "right" fallback fonts, and everything's good. So the user will end up seeing the expected result; but there might be a transient rendering with a different font.

(Note that this is something that'll generally only happen once per browser session: as soon as any global font-fallback search has happened, all font character coverage data will have been loaded into the shared font-list structures.)

So the tests that tend to be affected are those that involve "obscure" characters -- such as the stylized mathematical alphabets, letters from rare/ancient scripts, etc -- that are not supported by the default fonts being used (serif or whatever) and lead to a fallback search. The first such test that a browser session runs may hit the async-fallback situation and capture a "wrong" rendering, so to avoid that, we disable the async-fallback mechanism.

Comment 8

[Jamie Nicol [:jnicol]]

Thanks for the explanation. makes sense, and that puts me at ease