Open Bug 1520157 Opened 2 years ago Updated 4 days ago

SourceCodePro font rendered in wrong colour on osx (macOS)

Categories

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

Unspecified
macOS
defect

Tracking

()

Webcompat Priority ?
Tracking Status
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox80 --- wontfix

People

(Reporter: glob, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [webcompat])

Attachments

(4 files)

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

Attached image Screenshot

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

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

Setting this P2 since Dropbox is high profile.

Priority: -- → P2
Duplicate of this bug: 1534503

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.

Flags: webcompat?
Whiteboard: [webcompat]

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

Webcompat Priority: --- → ?

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

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

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

Keywords: regression

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.

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

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?

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.

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

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.

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.

(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.

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.

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

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.

(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.

Duplicate of this bug: 1663868

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

Summary: SourceCodePro font rendered in wrong colour on osx → SourceCodePro font rendered in wrong colour on osx (macOS)

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

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.

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

Thanks @emilio!

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

Ah, found it in about:config.

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

See Also: → 1665427
Duplicate of this bug: 1665427

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.

Duplicate of this bug: 1670392

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

You need to log in before you can comment on or make changes to this bug.