1685141 - WPT test fails for html/canvas/element/text-styles/2d.text.font.parse.complex.html

Status: UNCONFIRMED

(Core :: Graphics: Canvas2D, defect)

Description

[Aryan Agal]

WPT test for html/canvas/element/text-styles/2d.text.font.parse.complex.html fails

FAIL message: assert_equals: ctx.font === 'italic small-caps 12px "Unknown Font", sans-serif' (got italic small-caps 400 12px Unknown Font, sans-serif[string], expected italic small-caps 12px "Unknown Font", sans-serif[string]) expected "italic small-caps 12px \"Unknown Font\", sans-serif" but got "italic small-caps 400 12px Unknown Font, sans-serif"

Cross-browser tests (as of bug report):

Chrome	Edge	Firefox	Safari
PASS	PASS	FAIL	PASS

Comment 1

[Brad Werth [:bradwerth] | Out until Feb 2025]

Jonathan, when getting canvas.getContext().font, we're including font-weight which the WPT doesn't expect. Is this specced?

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to Brad Werth [:bradwerth] from comment #1)

Jonathan, when getting canvas.getContext().font, we're including font-weight which the WPT doesn't expect. Is this specced?

Well.... starting from the spec for canvas, we have:

The font IDL attribute [...] a CSS <'font'> value

and

On getting, the font attribute must return the serialized form of the current font of the context (with no 'line-height' component).

So canvas2d's font is treated (with some caveats) like the CSS font shorthand.

Syntactically, it's valid to include weight in the font shorthand, but the shorthand will reset it to normal (or 400) if omitted, so setting it to italic small-caps 400 12px Unknown Font, sans-serif is the same as setting it to italic small-caps 12px Unknown Font, sans-serif.

The question, then, is what the correct serialization of font should be. I think the relevant statement in CSSOM is the second bullet point of rule 2:

If component values can be omitted or replaced with a shorter representation without changing the meaning of the value, omit/replace them.

Which means that yes, the weight component should be omitted here, as that would not change the meaning of the overall font value.

However, the CSSOM spec goes on to say that

If [omitting it] would be less backwards-compatible, do not perform them.

and then goes on to add

Note: The rules described here outlines the general principles of serialization. For legacy reasons, some properties serialize in a different manner, which is intentionally undefined here due to lack of resources. Please consult your local reverse-engineer for details.

suggesting that all this is perhaps not so clear after all.

My conclusion, then, is that the "preferred" serialization of font here would be without the weight component, but if Gecko has historically always serialized it with the weight component, we could point to the backwards-compat/"legacy reasons" wording and claim that the spec allows this.

It looks like there's also an issue regarding quoting of the "Unknown Font" family name: the FAIL message appears to indicate that quotes are expected, but our serialization leaves it unquoted. The rules for font-family are a bit tricky, and probably it would have been better if it had simply required all names to be quoted, but there's a lot of legacy around this, and in fact the quote marks are not required here. Arguably, then, the CSSOM rule about "...replaced with a shorter representation..." means the quotes should be stripped (although the Fonts spec says "it is recommended to quote font family names that contain white space", suggesting it's nice to keep them).

All of which suggests that these tests may be a bit fragile; making assumptions about the precise serialization of the font shorthand seems risky.

Comment 3

[Jonathan Kew [:jfkthame]]

I see that Emilio commented on this earlier, actually:

html/canvas/element/text-styles/2d.text.font.parse.complex.html seems like a bug in the test that expects a particular serialization, so the test should be patched instead of Firefox changed.