SourceCodePro font rendered in wrong colour on osx (macOS)
Categories
(Core :: Graphics: Text, defect, P2)
Tracking
()
Webcompat Priority | P3 |
People
(Reporter: glob, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [webcompat])
Attachments
(5 files)
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.
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 6•6 years ago
|
||
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.
Updated•6 years ago
|
![]() |
||
Updated•6 years ago
|
![]() |
||
Updated•6 years ago
|
Comment 7•6 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 8•6 years ago
|
||
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.
Comment 10•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Comment 11•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 12•4 years ago
|
||
As of Firefox 80.0 (but not 79), this now affects the Rust Playground, which also uses Source Code Pro.
Comment 13•4 years ago
|
||
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?
Updated•4 years ago
|
Comment 14•4 years ago
|
||
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•4 years ago
|
||
Here's a screenshot of the Rust docs, which display correctly.
Comment 16•4 years ago
|
||
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.
![]() |
||
Updated•4 years ago
|
Comment 17•4 years ago
|
||
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•4 years ago
|
||
(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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
(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•4 years ago
|
||
Perhaps it would make sense to change the title from "osx" to "macOS" so it's more searchable?
![]() |
||
Updated•4 years ago
|
Comment 25•4 years ago
|
||
Does anyone know of any font rendering changes that occurred between 79 and 80 that could have caused this?
Comment 26•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
Thanks @emilio!
Can you disable WebRender from the settings or do you need a different build of Firefox?
Comment 29•4 years ago
|
||
Ah, found it in about:config
.
Comment 30•4 years ago
|
||
Yep, same here, it renders fine with WebRender but does not with the default.
Comment 32•4 years ago
|
||
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•4 years ago
|
||
Issue also seen on https://webpack.js.org with dark mode ( @media(prefers-color-scheme: dark)
). Setting webrender to true fixes it.
Comment 35•4 years ago
|
||
Sadly this the gfx.webrender.enabled
workaround is not working anymore with Big Sur.
Comment 37•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
•
|
||
(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
inabout: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•4 years ago
|
||
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•4 years ago
|
||
(Note that that setting needs a restart)
Comment 42•4 years ago
|
||
Yup, I did restart.
Comment 43•4 years ago
|
||
I also can confirm that it works with gfx.webrender.force-disabled=true
(I did restart).
Comment 44•4 years ago
|
||
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•4 years ago
|
||
I'm on macOS Catalina v10.15.6.
Comment 46•4 years ago
|
||
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•4 years ago
|
||
This is on macOS Big Sur (11.0.1) with 85.0a1 (2020-11-17) (64-bit)
Comment 48•4 years ago
|
||
SourceCodePro itself was now updated to fix this issue: https://github.com/adobe-fonts/source-code-pro/issues/217#issuecomment-728779289
Comment 49•4 years ago
|
||
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•4 years ago
|
||
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.
![]() |
||
Updated•3 years ago
|
Updated•2 years ago
|
Comment 51•2 years ago
|
||
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.
Updated•2 years ago
|
Description
•