1520157 - SourceCodePro font rendered in wrong colour on osx (macOS)

Status: RESOLVED INACTIVE

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

Description

[:glob ✱]

Attachment: test-case.html

the keyboard shortcuts on paper.dropbox.com are not rendering correctly - the text is appearing as black text on black background.

i've attached a reduced testcase.

appears to be an osx specific issue; unable to reproduce on windows.

Comment 1

[:glob ✱]

Attachment: Screenshot

Comment 2

[:glob ✱]

this is a regression, but it was introduced some years ago.

unfortunately due to a jemalloc issue (https://github.com/jemalloc/jemalloc/issues/420) i'm unable to run a wide range of builds.

best i can do is:

• Last good revision: 4d926af89907 (2014-04-28) firefox 31
• First bad revision: ffac2798999c (2016-08-01) firefox 50

Comment 3

[:glob ✱]

Attachment: paper.dropbox.com screenshot

here's the bug "in the wild" on paper.dropbox.com.

Comment 4

[Cameron McCormack (:heycam)]

Setting this P2 since Dropbox is high profile.

Comment 6

[Jonathan Kew [:jfkthame]]

I think basically what's happening here is that the font includes some SVG glyphs (for a bunch of emoji, no doubt). This causes us to render it via a "color font" codepath, and color fonts ignore the CSS color property as the glyphs are painted with their inherent colors instead.

But in this case many (most) of the glyphs do not actually have color versions, and so they simply paint as black. We need to be making the decision whether to paint "as a color font" (ignoring CSS color) on a per-glyph basis, not per-font-run, so that glyphs without inherent color don't just default to all-black all the time.

Comment 7

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 8

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 9

[Tom S [:evilpie]]

Another instance: https://www.reddit.com/r/rust/comments/fdj80k/caniusers_rust_feature_search/fji2nwf/ Sounds like other browsers don't have this problem.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 11

[Roel Nieskens]

Ran into this problem, and found this bug report. What Jonathan Kew says is indeed happening here. A handful of color glyphs (for music notes, playing card symbols) are included in the font: https://github.com/adobe-fonts/source-code-pro/tree/master/svg

Best option here would be to render non-SVG glyphs as regular glyphs, and only follow the color font rendering path when one of these 13 characters are being rendered.

Comment 12

[Jake Goulding]

As of Firefox 80.0 (but not 79), this now affects the Rust Playground, which also uses Source Code Pro.

Comment 13

[Camelid [:camelid]]

I also had this issue with another site using Source Code Pro in 80.0 but not before. Did this get fixed and then regress?

Comment 14

[Camelid [:camelid]]

Interestingly, this does not occur (for me) in the Rust docs, which also use Source Code Pro; e.g., https://doc.rust-lang.org/std/fs/fn.read_to_string.html.

Comment 15

[Camelid [:camelid]]

Attachment: The Rust docs, which also use Source Code Pro, don't seem to have this issue

Here's a screenshot of the Rust docs, which display correctly.

Comment 16

[Camelid [:camelid]]

Ah, according to Eric Huss, Rustdoc uses an older version to avoid this problem:

Yea, in rustdoc, it is intentionally using an older version of Source Code Pro to avoid this problem.

Comment 17

[Devon Govett]

As of Firefox 80 this seems to be affecting more pages. According to Font Book, Source Code Pro isn't installed on my system, yet Firefox seems to be resolving it somehow and rendering everything black. Did something change related to font rendering in Firefox 80?

For example, see https://react-spectrum.adobe.com/react-spectrum/Checkbox.html. If you inspect the text in one of the code examples and change the font-family declaration to remove "Source Code Pro" and just have Monaco, the color returns. In Safari, it seems that Monaco is rendered. In Chrome, something different from Monaco is rendered (maybe actual Source Code Pro somehow??), but it has correct colors. I am quite confused as to where Firefox/Chrome would be getting the font from given that it's not a web font and not installed on my system.

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to Devon Govett from comment #17)

As of Firefox 80 this seems to be affecting more pages. According to Font Book, Source Code Pro isn't installed on my system, yet Firefox seems to be resolving it somehow and rendering everything black.

Do you possibly have Adobe Creative Cloud running, or some other font manager software? A font manager like Creative Cloud can "activate" fonts and make them available to application -- such as Firefox and Chrome -- without the font being installed or visible in Font Book.

Comment 19

[Devon Govett]

Ah yes. Looks like it's Creative Cloud. That explains where it's coming from at least. I don't believe these were installed recently though. Several people on my team mentioned that it worked for them in Firefox 79 but as soon as they updated to Firefox 80 it stopped working. So I don't think it was a font update in this case.

Comment 20

[Cory Duncan]

As of Firefox 80, this bug is affecting a product I'm working on, leading to an unfortunate user experience. Is it accurate that this is "wontfix"?https://bugzilla.mozilla.org/show_bug.cgi?id=1520157#a50888678_279663

Comment 21

[Camelid [:camelid]]

You might be able to serve a bundled version of Source Code Pro that doesn't have this issue, which is what several Rust web projects do. It would be nice if this were fixed though.

Comment 22

[Jonathan Kew [:jfkthame]]

(In reply to urbanor from comment #20)

As of Firefox 80, this bug is affecting a product I'm working on, leading to an unfortunate user experience. Is it accurate that this is "wontfix"?https://bugzilla.mozilla.org/show_bug.cgi?id=1520157#a50888678_279663

It's "wontfix" for Firefox 80 (and earlier versions), given they've already shipped, and this isn't the kind of critical security issue that would justify issuing a dot-release to the shipping software.

The bug remains open for future versions, so I hope a fix can be developed at some point. In the meantime, there are possible workarounds such as using a different font, or a subsetted version of Source Code Pro that doesn't include the problematic SVG glyphs.

Comment 24

[Camelid [:camelid]]

Perhaps it would make sense to change the title from "osx" to "macOS" so it's more searchable?

Comment 25

[Camelid [:camelid]]

Does anyone know of any font rendering changes that occurred between 79 and 80 that could have caused this?

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Running mozregression, in particular, mozregression --good 79 --bad 80, in one of the affected systems where you see a regression (sorry, I'm not on OSX myself) is the easiest way to figure out.

Comment 27

[Jonathan Kew [:jfkthame]]

For me, this only occurs if webrender is disabled; when WR is in use, Source Code Pro gets colored as expected in these examples.

Comment 28

[Camelid [:camelid]]

Thanks @emilio!

Can you disable WebRender from the settings or do you need a different build of Firefox?

Comment 29

[Camelid [:camelid]]

Ah, found it in about:config.

Comment 30

[Camelid [:camelid]]

Yep, same here, it renders fine with WebRender but does not with the default.

Comment 32

[Kurt]

To anybody else who's not a Firefox dev, after changing gfx.webrender.enabled to true you have to restart FF for it to take effect.

Comment 34

[Emily Klassen]

Issue also seen on https://webpack.js.org with dark mode ( @media(prefers-color-scheme: dark) ). Setting webrender to true fixes it.

Comment 35

[beni.brossi]

Sadly this the gfx.webrender.enabled workaround is not working anymore with Big Sur.

Comment 37

[Camelid [:camelid]]

I'm no longer having this bug as of today -- I think Firefox 83 might have fixed it? (I checked, and gfx.webrender.enabled = false in about:config, so it's not that.) Either way, hooray!

Is it fixed for other people who were having this bug?

Comment 38

[Camelid [:camelid]]

Jake Goulding confirmed that Firefox 83 fixes it for them too! Whoever fixed this, thank you so much! I didn't realize how much this was driving me nuts until it was fixed :)

Comment 39

[Jonathan Kew [:jfkthame]]

(In reply to Camelid [:camelid] from comment #37)

I'm no longer having this bug as of today -- I think Firefox 83 might have fixed it? (I checked, and gfx.webrender.enabled = false in about:config, so it's not that.) Either way, hooray!

I wonder if you're now getting webrender by default, without needing the gfx.webrender.enabled setting?

To check, could you try running the browser with gfx.webrender.force-disabled=true, and see how that behaves? Thanks!

Comment 40

[Devon Govett]

I can also confirm it appears to be working in Firefox 83. I tried it with gfx.webrender.force-disabled=true as well, and it appears to work with that setting as well.

Comment 41

[Emilio Cobos Álvarez (:emilio)]

(Note that that setting needs a restart)

Comment 42

[Devon Govett]

Yup, I did restart.

Comment 43

[Camelid [:camelid]]

I also can confirm that it works with gfx.webrender.force-disabled=true (I did restart).

Comment 44

[Jonathan Kew [:jfkthame]]

Interesting; I still see the problem with both Firefox 83.0 and Nightly using the testcase here. What versions of macOS are each of you running?

Comment 45

[Camelid [:camelid]]

I'm on macOS Catalina v10.15.6.

Comment 46

[Devon Govett]

I'm still on Catalina: 10.15.4. Someone on my team mentioned it might still be happening for them on Big Sur.

Comment 47

[Karl Dubost💡 :karlcow]

Attachment: macos-11-big-sur-nightly-85

This is on macOS Big Sur (11.0.1) with 85.0a1 (2020-11-17) (64-bit)

Comment 48

[Tom S [:evilpie]]

SourceCodePro itself was now updated to fix this issue: https://github.com/adobe-fonts/source-code-pro/issues/217#issuecomment-728779289

Comment 49

[Jonathan Kew [:jfkthame]]

Interesting - according to the issue there, people were seeing the same issue in other applications as well on Big Sur. Glad they've decided to fix this in the font, although it'd still be nice to solve it consistently on the Firefox side as well if possible (given that there are doubtless other affected fonts out there, though SCPro is probably the most widespread).

Comment 50

[Emilio Cobos Álvarez (:emilio)]

So someone linked me to this test-case, which I think it's showing the same issue, but maybe it's easier to see what's going on.

Comment 51

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 7 See Also bugs.
:lsalzman, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.