Wrong font metrics used when font-family doesn't exist

[AtkinsSJ]

Summary

When the font-family for an element only consists of fonts that are not available, we end up using metrics from a different font than we render with. This produces odd gaps between words, and strange selection behaviour.

Operating system

Linux

Steps to reproduce

1. Open the test case below.
2. Notice that there are funky gaps.

Expected behavior

There are no funky gaps.

Actual behavior

There are funky gaps.

URL for a reduced test case

N/A

HTML/SVG/etc. source for a reduced test case

<style>
html { font-family: lololol; }
</style>
Well hello friends!

Log output and (if possible) backtrace

N/A

Screenshots or screen recordings

This is the reduced test case above. Here I've selected the word "hello" but the selection area extends beyond it.

Build flags or config settings

No response

Contribute a patch?

• I’ll contribute a patch for this myself.

[AtkinsSJ]

I believe what's happening is that we end up with a font stack of only Noto Color Emoji, which explains why the metrics are wrong. (Emoji are square.) But then we use the fallback font for actually painting the text.

[AtkinsSJ]

A correction: The rendered font is in the stack, but after the emoji font. The issue is that we always use the metrics from the first usable font in the stack, not the font that actually renders that glyph.

[manuel-za]

I may have found the issue StyleComputer::compute_font_for_style_values: when a font is not found, only the emoji font is added to the stack.
PR coming shortly...