1589156 - CSS color is ignored when using @font-face font

Status: NEW

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

Description

[jeremyrsmith]

Attachment: font-face-color-bug-repro.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

1. Create an HTML document with an @font-face rule providing the Hasklig font in OTF format (font and HTML are attached).
2. Specify a CSS class (e.g. "example") with font-family: Hasklig and color: red.
3. Add an HTML element with class="example" and some text content.
4. View the page in Firefox – bug produced on 69.0.3 (64-bit), MacOS Mojave 10.14.6 (18G95).

Actual results:

The text is black.

Expected results:

The text should be red.

If the Hasklig font is installed, and the @font-face rule is removed, then the text correctly displays as red.

Comment 1

[jeremyrsmith]

Attachment: with-font-face.png

This is how the text appears when the @font-face rule is present.

Comment 2

[jeremyrsmith]

Attachment: without-font-face.png

This is how the text appears when the @font-face rule is removed, if the user has the Hasklig font installed.

Comment 3

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
20191009172106

Works for me. Enter about:profiles into the address bar. Create a new profile, then click the Launch profile in new browser button below it. Can you reproduce the issue there?

Comment 4

[jeremyrsmith]

Yes, the issue still occurs on a new profile, and even on a fresh install of Firefox.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0

Comment 5

[Emilio Cobos Álvarez (:emilio)]

This works for me too, on Linux though. Could you attach your about:support? Also, does getComputedStyle return the right (red) color?

I honestly have no idea what could cause this... Jonathan, any idea?

Comment 6

[Jonathan Kew [:jfkthame]]

Seems odd... it works for me on macOS 10.13.6, too. Tried a few versions, including both 69.0.3 and Nightly.

The font has an 'SVG' table, which means it may take a different rendering path than "normal" (monochrome) fonts, but I don't see why it would behave differently when loaded via @font-face vs locally installed, nor why it works for me but not for the reporter.

Maybe there's a difference between 10.13 and 10.14 that's significant here.

Comment 7

[jeremyrsmith]

Attachment: Here's my about:support information

Comment 8

[jeremyrsmith]

Attachment: computed-style.png

Calling window.getComputedStyle(el).color does indeed return rgb(255,0,0). Also, as shown, firebug shows the element's color to be red, even while it's appearing black.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to jeremyrsmith from comment #8)

Calling window.getComputedStyle(el).color does indeed return rgb(255,0,0). Also, as shown, firebug shows the element's color to be red, even while it's appearing black.

Yes, that's what I would expect. This isn't a bug in CSS computation, it's a bug in the actual painting - but I'm not sure why it fails for you, when it appears correctly for me on macOS 10.13.

Seems like more of a Graphics:Text issue than Layout, actually. Maybe one of the Graphics team has a machine running 10.14 and can try reproducing this.

Comment 10

[jeremyrsmith]

Attachment: Hasklig-Regular-1.otf

I installed FontForge, opened the font, and immediately saved a new copy as "OTF (CFF)" with all default settings. Not sure what the CFF part means or if that's different than the original file. But when using the exported copy as a web font, it works correctly and displays as red. It must be something with that particular font file.

Comment 11

[Jonathan Kew [:jfkthame]]

The bug you were seeing is triggered by using a font that includes colored glyphs. FontForge has removed the SVG glyphs from the font (I'm not sure what they were -- probably various emoji or other multi-colored symbols), as it doesn't support that feature, so that your new copy is now a standard monochrome OpenType font.

Comment 12

[jeremyrsmith]

You're right; looking at the source, it does inexplicably have emoji and colorful SVG glyphs. I'm not sure why a programming font would include those, but they won't be missed in my app, so this workaround is fine for me at the moment. I am curious, though, why they impact regular glyphs (and especially why they only seem to do so on a specific version of Mac OS).

Comment 13

[Timothy Nikkel (:tnikkel)]

I also cannot reproduce with macOS 10.13.

Comment 14

[Timothy Nikkel (:tnikkel)]

I asked a friend to test on 10.14 and they saw black text, so it appears to be something specific to 10.14. I wonder if anyone has tested with 10.15.

Comment 15

[Timothy Nikkel (:tnikkel)]

So is this likely our bug or an Apple bug? What are next steps here?

Comment 16

[Jonathan Kew [:jfkthame]]

I'd guess it's a change in behavior of a Core Text API that we need to account for in our code. It's probably not something Apple would consider a bug; rather, they've added some support for fonts with embedded SVG glyphs, but a side-effect of this is that such fonts now render (even their non-SVG glyphs) using their "inherent" color and ignore any color set in the context. So we'd need to figure out a new rendering path for non-SVG glyphs in such a font, in order to apply the foreground color we want.

(Note that the above is just my current guess as to what may be happening, not necessarily an accurate diagnosis, but I feel reasonably sure it'll be along those lines.)

Comment 17

[Roland]

Is it possible that this bug is affecting adventofcode.com site rendering for me?

Comment 18

[Roland]

Attachment: Screenshot on 2020-09-13 at 09:27:23.png

Comment 19

[Roland]

I'd like to point out that this bug (if this is indeed caused by this particular issue) is breaking quite a lot of the web ritght now.

A considerable chunk of the web that I frequently visit that use custom fonts of one sort or another are affected:

• Abovementioned adventofcode page
• Rust API documentation code samples
• few other pages that use custom fonts for rendering code blocks.

Comment 20

[Jonathan Kew [:jfkthame]]

The adventofcode site seems to display fine for me on macOS 10.15.

Ohhh.... you probably have a copy of Source Code Pro installed locally, and so your browser is using that rather than the site's webfont (which doesn't have the issue). If you disable your installed copy in Font Book, does that fix the adventofcode site?

Comment 21

[Roland]

Quite interesting. Indeed, disabling Source Code Pro from FontBook has fixed the font rendering on adventofcode.

Further researching it grom the angle of SourceCode Pro, I found that I have most likely been hit by #1520157

All in all, these two issues seem to be related (i.e. both basically say that font rendering ignores style color when font contains SVG glyphs)

Comment 22

[Roland]

As with bug #1520157 the "workaround" that also seems to work is to enable WebRender (i.e, gfx.webrender.enabled = true)