Closed Bug 1598063 Opened 1 year ago Closed 1 year ago

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

Categories

(Core :: Canvas: 2D, defect, P3)

70 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla73
Tracking Status
firefox73 --- verified

People

(Reporter: simon.sarris, Assigned: jfkthame)

Details

(Keywords: testcase)

Attachments

(2 files)

Attached file 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.

Has STR: --- → yes
Component: Untriaged → Canvas: 2D
Keywords: testcase
Product: Firefox → Core

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

:lsalzman, can you comment to the bug?

Flags: needinfo?(lsalzman)
Priority: -- → P3

Jonathan, webfont issue?

Flags: needinfo?(lsalzman) → needinfo?(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.)

Flags: needinfo?(jfkthame)

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.

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.

Assignee: nobody → jfkthame
Pushed by jkew@mozilla.com:
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
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73

❤ u guys

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.