1565588 - Starting with Firefox 68 on Ubuntu, in some cases numbers and spaces are not printed and page formatting is incorrect; problem is much worse on 69 beta (+ if WebRender is enabled, it says: "Unable to set glyph size and transform: 23")

Status: NEW

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Michael Marley]

Attachment: firefox_rendering_issue.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) Arora/0.11.0 Version/10.0 Safari/602.1

Steps to reproduce:

Start Firefox
In 68, navigate to an affected page. In 69, just look at the browser UI.

Actual results:

In 68, some pages would fail to display numerical characters and spaces and sometimes the formatting would be screwed up also.

In 68, this seems to apply to most of the UI elements, including the tab bar, the address bar, the search bar, and all menus.

Expected results:

Numbers and spaces should print correctly in all cases.

More details:
This problem initially began on Firefox 68 beta, installed from the Firefox beta PPA (https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next) on a Kubuntu x86_64 system. Then, it only affected a small number of pages. The problem continued with Firefox 68 final in the official Ubuntu repository. Starting with the 69 beta (specifically, beta 4), the problem has begun to affect the UI elements of the browser as well, as demonstrated by the attached partial screenshot. This issue does not seem to be related to WebRender as it happens with WebRender on and off. When WebRender is on, however, "ERROR 2019-07-12T14:33:52Z: webrender::platform::unix::font: Unable to set glyph size and transform: 23" is printed to the console. To work around this, I have tried a fresh Firefox profile and setting different default fonts both in KDE and in Firefox. Neither of those has any effect.

Comment 1

[Darkspirit]

(Michael Marley from comment #0)

This issue does not seem to be related to WebRender as it happens with WebRender on and off.
When WebRender is on, however, "ERROR 2019-07-12T14:33:52Z: webrender::platform::unix::font: Unable to set glyph size and transform: 23" is printed to the console.

This error message was introduced by bug 1562892.

Comment 2

[Jonathan Kew [:jfkthame]]

Could you give an example (or two...) of specific pages -- the address of the page, together with a screenshot of the bad rendering you're seeing -- where you see this problem within the web page content? Thanks!

Comment 3

[Michael Marley]

Attachment: An example webpage demonstrating missing spaces and numbers within the content

The websites I have been having a problem with are mostly internal to my employer and I can't use those as an example, so I made something myself: https://michaelmarley.com/downloads/misc/firefox_1565588_demo.html. The text all prints normally except in side the list view and the text boxes, where no spaces or numbers are printed.

Honestly though, the occurrence of this issue in the brower UI elements (as shown in the first screenshot I posted several days ago) is much more annoying than when it happens in pages as this makes it very difficult to type any URL or search string that contains number or spaces or to do in-page searches.

Comment 4

[Jonathan Kew [:jfkthame]]

OK, so this has something to do with how the system font is configured, I think. It doesn't happen on my Ubuntu system, fwiw -- but no doubt my font configuration is different.

Using your example page, please try right-clicking on the text in the list view, and choose Inspect Element from the context menu; then on the right-hand side of the inspector, select the Fonts panel. What does it show for "Fonts Used" of the options in the list view?

Comment 5

[Michael Marley]

I did that and I saw "DejaVu Sans Oblique" (which is expected because that is the font I have configured), but also "EmojiOne". I didn't really even intend to have that font installed on the system; it was just still installed from back a long time ago when it was the only color Emoji font in Ubuntu. I removed it and restarted Firefox, which caused the problem to stop occurring. It is still rather curious why this was happening and why it just started with 68 and got worse with 69 though.

Comment 6

[Jonathan Kew [:jfkthame]]

Aha! I suspect that your fontconfig rules were set up such that it "inserts" EmojiOne in front of DejaVu in some way, so that emoji will render from the color font rather than DejaVu's monochrome glyphs. But EmojiOne also thinks it supports the digit characters (in order to implement emoji-style combinations of digit + keycap), but the bare digits don't have an appearance of their own; and it has a <space>, but the <space> has zero width. And because it's being inserted ahead of DejaVu, we end up "drawing" the digits and space from the EmojiOne font, where they don't actually produce anything.

There have been some changes in how emoji fonts are configured recently, which might explain why the problem became worse, but I'm not exactly sure offhand. Possibly Kato-san might be interested to check what's going on here.

Comment 7

[Makoto Kato [:m_kato] (PTO until 5/6)]

I don't know why number glyph appies emoji one. When I test this on my Ubuntu 18.04, I cannot reproduce this. Ubuntu's fontconfig has an entry that emoji one is "emoji" only. If user assigns that emoji one is serif or san-serif, it may occur. Does user modify font config's setting (via /etc/fonts/*, ~/.fonts.conf or ~/fontconfig)?

Comment 9

[ashish.mohite]

Attachment: PageNumber_Demo.html

Comment 10

[ashish.mohite]

Page number counter not working properly in Firefox 68 version =>

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Added counter for page number in print.

Note : It is working for earlier version properly.

Actual results:
Showing total number of pages in first page at page number section and in other pages it is showing blank page number

Expected results:
Need to show proper page numbers like 1, 2, 3, 4 on each page respectively in header section

PFA => PageNumber_Demo.html

Comment 11

[smarter3]

Same issue on Ubuntu 20.10 when using the followi g ~/.config/fontconfig/fonts.conf (without this, various applications cannot display emoji at all):

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <dir>~/.fonts</dir>
 <alias binding="strong">
   <family>sans-serif</family>
   <prefer>
     <family>emoji</family>
   </prefer>
 </alias>

 <alias binding="strong">
   <family>serif</family>
   <prefer>
     <family>emoji</family>
   </prefer>
 </alias>

 <alias binding="strong">
   <family>monospace</family>
   <prefer>
     <family>emoji</family>
   </prefer>
 </alias>
</fontconfig>

Comment 12

[smarter3]

To reproduce, I'll note that this happens for me on https://en.wikipedia.org/wiki/Main_Page for example but not on https://xkcd.com/, it also happens in Firefox dialog boxes and the Firefox console.

Comment 13

[smarter3]

Using alias binding="weak" instead of alias binding="strong" fixes the problems (I see spaces between words on Wikipedia now).

Comment 15

[Daniel Holbert [:dholbert]]

Reporter (Michael): if you can still reproduce this, could you confirm whether you have anything in ~/.config/fontconfig/fonts.conf (anything like comment 11)?

It would be useful to know if you and @smarter3 (from comment 11) are coming at this with some similar configuration there, vs. if you might be hitting completely independent issues that happen to have similar symptoms.

Comment 16

[smarter3]

I've found another way to reproduce the problem: even with an empty ~/.config/fontconfig/fonts.conf, if I go to https://www.kamesame.com/app/login, I don't see spaces between words in the text the bottom ("In order to track your progress ..."), the font used for the text is selected using font-family: system-ui, emoji, sans-serif, ..., if I remove emoji from the list then the text is displayed correctly. There's an open bug report about this problem in the Noto repository, but according to them it's a Firefox bug: https://github.com/googlefonts/noto-fonts/issues/753

I don't know what to do with this bug. Noto Color Emoji does have a space character, all Noto fonts do. The space character is the width of a standard emoji character. Many browsers/environments seem to handle this ok, they do at least render a space. The fact that firefox/xubuntu fails to render it entirely seems like a bug between the browser/os. It doesn't seem like our problem.

Comment 17

[Michael Marley]

I'm not able to reproduce this any longer, sorry.

Comment 18

[raphael]

Recent upgrade to Firefox 99 here (Archlinux), the problem appears. Downgrading to Firefix 98 works.
Some pages are affected, others are not. Though, most UI elements are affected:

• about:preferences
• the Startup dialog when using Firefox -P
• the Restore session dialog
• main/contextual menus
• the text editor in the Inspector Dev-tool interface

My fontconfig/fonts.conf has the following:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<fontconfig>
  <dir>~/.fonts</dir>
  <match target="font">
    <edit mode="assign" name="antialias">
      <bool>true</bool>
    </edit>
  </match>
  <match target="font">
    <edit mode="assign" name="hinting">
      <bool>true</bool>
    </edit>
  </match>
  <match target="font">
    <edit mode="assign" name="hintstyle">
      <const>hintmedium</const>
    </edit>
  </match>
  <match target="font">
    <edit mode="assign" name="rgba">
      <const>none</const>
    </edit>
  </match>
  <match target="font">
    <edit mode="assign" name="lcdfilter">
      <const>lcddefault</const>
    </edit>
  </match>
  <match target="font">
    <edit mode="assign" name="embeddedbitmap">
      <bool>false</bool>
    </edit>
  </match>
</fontconfig>

I also have 3 files in fontconfig/fonts.d, apparently related to emoji and DejaVu (which, given the discussion here seems to be involved).

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to raphael from comment #18)

I also have 3 files in fontconfig/fonts.d, apparently related to emoji and DejaVu (which, given the discussion here seems to be involved).

It's very likely caused by whatever emoji configuration file you have. Could you attach it here (see the Attachments section near the top of the page) for us to check what it's doing? Thanks.

Comment 20

[raphael]

Attachment: 69-emoji.conf

Comment 21

[raphael]

Attachment: 70-no-dejavu.conf

Comment 22

[raphael]

Attachment: 30-icons.conf

Comment 23

[raphael]

Attachment: Screenshot_2022-04-16-19_881x500.png

Comment 24

[raphael]

I have just attached the 3 files from my ~/.config/fontconfig/conf.d folder (30-icons.conf 69-emoji.conf 70-no-dejavu.conf).

I have also removed my fontconfig/fonts.conf file, and I have attached a screenshot of my Firefox interface without anything in ~/.config/fontconfig/. You may see the weird number rendering (big, bold, white, even on white background), and the abnormal space rendering (in the text, some spaces are as wide as tabs, such as between "Positionnement" and "de").

Thanks for the help.

Comment 25

[Jonathan Kew [:jfkthame]]

What happens if you remove the 69-emoji.conf file (at least temporarily, for testing)?

Comment 26

[raphael]

The problem persists, with the [GFX1-]: Unable to set glyph size and transform: 23 message.
Spaces and numbers are not printed, at all. I have tried to remove other files, but could not restore a normal state.

As far as I can tell, the problem seems to have started with this package update upgraded fontconfig (2:2.13.96-1 -> 2:2.14.0-1). However, I noticed with a previous update that emojis had started to get bigger (but it wasn't a big problem, I did not bother to try to fix it).

Comment 27

[Jonathan Kew [:jfkthame]]

I suspect there's still an emoji-related configuration file that is causing the issue: probably something installed at the system level rather than in your personal ~/.config/fontconfig folder.

Does fgrep -r -i emoji /etc/fonts find anything on your system (assuming /etc/fonts is the proper location for system-wide font setup on Arch Linux)?

Comment 28

[raphael]

(In reply to Jonathan Kew (:jfkthame) from comment #27)

I suspect there's still an emoji-related configuration file that is causing the issue: probably something installed at the system level rather than in your personal ~/.config/fontconfig folder.

Does fgrep -r -i emoji /etc/fonts find anything on your system (assuming /etc/fonts is the proper location for system-wide font setup on Arch Linux)?

Yes! Thank you very much for your help!
There were 3 files in /etc/fonts/conf.avail, named 56-emojione-color-font.conf, 56-ttf-twemoji-color.conf and 75-noto-color-emoji.conf, found thanks to your command. I don't remember putting them there, I guess they were placed when the font packages were installed.

I removed them, and it seems to work as before the update.
Again, thank you very much for your very quick and efficient help!

Comment 29

[Aitor]

Same here in OpenSUSE TW. After FF 99 upgrade, I started hitting this bug. Removing the <string>Noto Color Emoji</string> <match>...</match> block in /etc/fonts/local.conf fixed the issue in FF at the cost of loosing colored emojis in my terminal.

Comment 30

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.