1535215 - a large black or white square follow by a black pawn creates a larger than normal black pawn

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect)

Description

[firefox]

Attachment: Annotation 2019-03-13 210401.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Steps to reproduce:

console.log("\u265F\u2B1C\u265F");

Actual results:

pawns following a square are enlarged

Expected results:

pawn should have stayed normal size

Comment 1

[firefox]

Attachment: firefox

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4c130e2f5246501268180ec4399f8b5acc584e05&tochange=c0bf622859f64edad0f259277758bbbe11bb3cbf

Regressed by Bug 1480798

Zibi,
Your patch seems to cause the regression.
Can you please look into this?

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

Any gut feeling on why document's directionality would impact font selection (?) or in some other way cause the tofu?

Comment 4

[Jonathan Kew [:jfkthame]]

Not directionality, but the patch mentioned in comment 2 also sets the lang attribute on the document, and that definitely affects font selection, because default fonts are specified via the per-langGroup preferences (font.name-list.<generic>.<langGroup>).

(There's no tofu here, btw; the square is simply a Unicode character U+2B1C WHITE LARGE SQUARE.)

The difference in the pawns is happening because of how font fallback is implemented. These are characters that are not present in the default monospace font being used, so fallback comes into play. The first pawn gets assigned whatever fallback font we happen to find for it. Then we get to the square. That also needs fallback. Now, one feature of our font fallback algorithm is that it tries to keep using the same fallback font for a series of characters, where possible (to reduce the ransom-note effect of doing a totally independent fallback on each separate character). In this case, the font that was picked for the pawn doesn't support the white square. So we have to switch to a different fallback font.

Then we get to the second pawn. Again, the fallback code prefers to keep using the same font; in this case, the font that was chosen for the square does support the pawn character as well, and so that's what gets used.

So, not really a bug; it's a known quirk of the font fallback behavior, where it's trying to minimize font-switching but there are inevitably some cases where the result is a bit surprising.

Comment 5

[Jonathan Kew [:jfkthame]]

Oh, one more note just for completeness: this behavior of the font fallback code -- attempting to use the same font as the preceding character -- is not just about reducing ransom-note effects, it's also a performance optimization, on the basis that it's common for fallback to involve a series of related characters. So once we've found a suitable font for the first one, it's usually a lot faster to first try that same font for the next character, rather than searching from scratch each time.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

reporter - does this answer satisfy you? Can we close this bug?

Comment 7

[firefox]

Yes,
thanks for the quick and thorough response!

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

Thank you!