Description of the issue:
Emoji are displayed as monochrome line art, or simply with a blank box. (See attached image)
Emoji display correctly in Chromium (79.0.3945.79) and Firefox (71.0).
How can this issue be reproduced?
Install Ubuntu 19.10
Install the latest Debian version of Brave(1.1.23)
Expected result:
Emoji should be displayed in color like every other browser.
Brave Version( check About Brave):
Brave Version 1.1.23 Chromium: 79.0.3945.88
Additional Information:
This issue has been reported multiple times but seems to be ignored.
Here are two threads regarding this issue that were left until they auto-closed due to inactivity:
I would also like to point out that “emoji” on this forum are displayed as png files. They are not rendered as a font like a true emoji. For this reason, troubleshooting this issue by looking at emoji on this forum is pointless. Brave renders png files just fine. However, it does not render emoji.
I have included a screenshot showing from left to right: Brave, Chromium, Firefox.
I was able to get a majority of emoji to work by (in the terminal):
sudo apt-get install fonts-noto-color-emoji
After you do this, make sure any instances of Brave are closed, then restart the browser. Granted, it’s a partial solution, but something is better than nothing, I guess. And, I’m with you. I have no idea why this being ignored by the devs.
This was tested with default browser settings. Can you try visiting the site with a fresh profile or private window? I’d like to see if any of your installed exgtensions may be conflicting with the way the emoji are displayed.
I get the same result, even in a private window and new profile (Ubuntu 18.04). I also need to point out that Chrome does this as well (at least on my computer). I’m wondering if it’s a Unicode issue.
Just providing an update.
On a fresh Ubuntu 19.04 VM sriram is right, Brave and Chromium both show monochrome emoji.
I was able to fix both Brave and Chromium by closing both browsers and running:
sudo apt install --reinstall fonts-noto-color-emoji
But I don’t understand why that fixes them, so I’m not satisfied.
First of all, why on my host machine is Chromium displaying color emoji but Brave isn’t. I would expect them both to work or both to fail. Granted, I haven’t applied the “fix” to it yet, but I would like to understand how it’s even possible for only one to succeed when they both pull from the system fonts.
Second, what is it about reinstalling the noto font that fixes it. I doubt the files are being changed (though I haven’t checked yet), so I’m leaning toward something in the fontconfig triggers. But the output of “fc-list -v” and “fc-cat -v” is unchanged before and after the reinstall. I probably don’t have a good enough understanding of fontconfig to figure this out at the moment, but hopefully I’ll find time to dive deeper if no one else beats me to it.
I extracted the files from the fonts-noto-color-emoji deb package and compared its contents with the files already on my system. The files’ checksums all matched.
So, I ran a strace on apt while reinstalling the deb package. After staring at the strace log for as long as I could stand, I still couldn’t figure out why reinstalling fixes emojis.
At this point, I’ve given up. I ran the fix on my host machine, and it worked.
@Citizen-Se7en
I’m very curious why only some of your emoji are working.
Please try closing Brave, performing a full system update, then run the following command:
sudo apt install --reinstall fonts-noto-color-emoji
Now open Brave. Does getemoji.com look correct now? If you still see about half working, please right-click an emoji in the list, click “Inspect”. Now in the bottom right frame that appears, scroll to the very bottom. What does it say under “Rendered Fonts”?
That’s unfortunate. If you’d like me to continue troubleshooting your browser, please finish the rest of the troubleshooting steps I mentioned. If you’d rather not, that’s fine, no pressure.
On getemoji.com, please right-click an emoji in the list, now click “Inspect”. In the bottom right frame that appears, scroll to the very bottom. What does it say under “Rendered Fonts”?
Times New Roman—Local file(103 glyphs)
DejaVu Sans—Local file(66 glyphs)
Noto Color Emoji—Local file(41 glyphs)
Noto Sans Symbols2—Local file(1 glyph)
I am also having the same issue. This is what my Rendered Fonts looks like
Liberation Serif—Local file(103 glyphs)
DejaVu Sans—Local file(66 glyphs)
Noto Color Emoji—Local file(41 glyphs)
Noto Sans Symbols2—Local file(1 glyph)
Interestingly I had font-symbola installed and removing that reduced the number of monochrome emojis. When I try to remove Liberation it seems tied to Brave. So I am wondering if that’s got to do something…
Please try running the following command in a terminal and let me know if it resolves the issue. Do NOT run it with sudo. It will create a symlink to the Noto Color Emoji font in your local user’s font directory. The shopt command will allow it to get the .uuid file and the change to shopt will only persist for that terminal session. This is one long command; for an accurate test, please don’t break it up. Just copy, paste, run: shopt -s dotglob; mkdir -p ~/.fonts/truetype/noto; ln -s /usr/share/fonts/truetype/noto/* ~/.fonts/truetype/noto
Thank both for providing the requested information. It was very helpful.
Sorry for the delay in my response. I don’t have as much time to dedicate to this as I would like.
This bug feels tied to fontconfig, but something seems off.
One time I had Chromium working when Brave wasn’t, and one time I had Brave working when Chromium wasn’t. If this was strictly a fontconfig issue, that shouldn’t be possible.
Even so, fontconfig remains the most likely culprit in my opinion although I can’t explain it.
I also found that reinstalling Noto Color Emoji is not a permanent fix. Emoji on my hypervisor and VMs all broke again over time.
So far in my testing, the symlink method above has survived reboots and updates, so I’m hopeful it will work for you as well. The more people testing it, the faster we can find out if it works, or if it too breaks.
Looks like I’m not going to get any more feedback regarding this issue.
So far the fix in my previous post continues to work so I’ll mark it as the solution.
Hi.
I’ve just started using Brave the other day, and I have the same problem with emojis.
I’m using Windows 7 though, but I figured that it would be better to respond here than start a new thread.
When you say to run a command in a terminal, would the equivalent in Windows be to run the command in command prompt?
if I need to change anything from the command you posted, please let me know :-).
You say not to run it with Sudo. Is this something I need to worry about in Windows? I’ve only installed Brave and one extension in Brave and done nothing else, except import my bookmarks.
I haven’t tried your other suggestions, as the command line seemed to be what worked for the others, if I understand it correctly.
The solutions discussed in this thread are specific to the way Linux handles fonts. If you’re running Windows, don’t try anything mentioned in this thread. Nothing discussed here is applicable to Windows. Even if you converted the shell commands to Windows and tried running them, it wouldn’t resolve a font issue in Windows because Windows doesn’t handle fonts the same way Linux does.
I said not to run the command with sudo for several reasons. The command I provided is actually 3 commands together. If sudo is only placed in front of the first command, it will cause shopt to fail. This is turn will cause the following cp command to miss any dot files such as the .uuid file. If sudo is placed in front of all of the commands I provided, the .uuid file will still be missed due to shopt failing, but also the resulting files and folders will be owned by root instead of the current user. In both scenarios, it’s likely the solution will still work. But I consider it poor practice to have root own files in a user’s home directory, and as I was hoping for troubleshooting feedback, I wanted everyone to try my troubleshooting steps exactly.
If you’re having font problems in Windows, I recommend creating a new thread to get more exposure from those with greater Windows experience.
Good luck friend.
As a followup for those who are curious, this issue is definitely not Brave’s fault. Ubuntu has an open bug for it. And there’s a report that the issue persists in the Ubuntu 20.04 beta. Since 20.04 is due to be released in a couple weeks, it’s likely this bug (and the workaround fix I provided) will continue in 20.04. Hopefully it get’s a proper fix eventually. https://bugs.launchpad.net/ubuntu/+source/fonts-noto-color-emoji/+bug/1859926?comments=all
