1598063 - The canvas context will not render fonts (or weights!) that have not been used on the page elsewhere

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect, P3)

Description

[Simon Sarris]

Attachment: fontBugFirefox.html

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

Steps to reproduce:

Create a canvas and 2d context, set its

context.font = "some custom font"

and paint the font. Nothing will appear unless the font is also present within the CSS of the page, such as in a <p> tag.

Attached is an HTML example that reproduces the issue. It happens with multiple fonts (I tested Roboto and Lato), and multiple weights (If Roboto bold is present in a paragraph, but NOT Roboto normal weight, then Roboto normal weight will fail to draw on the canvas).

Actual results:

Canvas draws nothing, instead of drawing either the font or even one of the fallbacks.

Expected results:

Canvas either draws the font, if loaded, or draws fallback font family.

Comment 1

[Simon Sarris]

Oops forgot to mention: You need to Disable Cache in the network tab in order to reproduce consistently.

Comment 2

[Sotaro Ikeda [:sotaro]]

:lsalzman, can you comment to the bug?

Comment 3

[Lee Salzman [:lsalzman]]

Jonathan, webfont issue?

Comment 4

[Jonathan Kew [:jfkthame]]

Yes. If the font hasn't already been loaded (e.g. because it was used elsewhere on the page), the first canvas drawText or measureText call will trigger a download of the font resource. But unless it's really fast, the resource probably won't be fully downloaded and instantiated ready for use, and so content trying to use that font will paint blank (unless the font-display timeout has expired, in which case we'd fall back).

For HTML text, when the font becomes available we'll trigger a reflow and repaint it, but canvas is independent of the HTML reflow/repaint cycle and won't get redrawn unless the page explicitly redraws it from JS.

This is a case where the page should be using the Font Loading API to ensure that the resources it wants are loaded and ready before doing the canvas drawing.

(Maybe we should try to make canvas drawing always fall back if the font isn't ready yet, which seems to be what Chrome does here; then at least something would appear, although it wouldn't be the author's intended font.)

Comment 5

[Simon Sarris]

I agree that broadly speaking one ought to be managing their assets and making sure they are loaded, but its still surprising that nothing at all renders. So I think the normal font fallback would be fix enough, since its what the rest of the browser experience does.

Comment 6

[Jonathan Kew [:jfkthame]]

Yes, I think I agree... we should just draw the fallback font here, because (unlike HTML text) the canvas text won't automatically get refreshed when the font load completes, and drawing nothing is a bad user experience.

With a patch to do this, we get the same behavior as Chrome on this testcase: on first load, the canvas text is rendered with a fallback bold font (Helvetica Bold in my case on macOS, likely Arial Bold on Windows, etc). On reloading the page, it switches to Roboto Bold, as the first time through triggered the font load, and so by the time we reload the page (without clearing caches) the font is available.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1598063 - Don't hide text styled with a pending user font when drawing canvas text, just draw with fallback instead. r=heycam

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b8ed043e32ed
Don't hide text styled with a pending user font when drawing canvas text, just draw with fallback instead. r=heycam

Comment 9

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/b8ed043e32ed

Comment 10

[Simon Sarris]

❤ u guys

Comment 11

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced the issue with Firefox 72.0a1 (20191122214053) on Windows 10x64.
The issue is verified fixed with Firefox 73.0b5 (20200115020958) on Windows 10x64, macOS 10.15 and Ubuntu 18.04. The font is correctly drawn on the attached testcase.