1638585 - When disabling "Allow pages to choose their own fonts", Material Icons ligatures display text instead of icons

Status: RESOLVED DUPLICATE of bug 1363454

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

Description

[nyanpasu64]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

• In Options (about:preferences), scroll to Fonts and Colors, click Advanced, and uncheck "Allow pages to choose their own fonts, instead of your selections above". Alternatively go to about:config and set browser.display.use_document_fonts to 0.
• Visit a page using Material Icons (eg. https://material.io/resources/icons/?style=baseline )

Actual results:

All buttons display text instead of a graphic.

On some websites, the buttons become too large. In other websites, the text overlaps, making sites unusable.

Expected results:

Buttons display icons.

Cause

The "Material Icons" webfont doesn't map Unicode codepoints to icons, but instead words to icons (via ligatures). If you disable browser.display.use_document_fonts, Firefox renders the text in sans-serif or serif, instead of "Material Icons".

Solution

I think Firefox already has code for detecting Unicode PUA-based icon fonts and using the webfont anyway. I don't know if it can be generalized to detect ligature-based icon fonts.

Notes

I downloaded Material Icons from https://github.com/google/material-design-icons/blob/master/iconfont/MaterialIcons-Regular.ttf and dragged it into https://fontdrop.info/ , revealing 979 ligatures.

Comment 1

[nyanpasu64]

Attachment: Screenshot of "better onetab" extension with broken layout and overlapping text

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi

I downloaded Material Icons from https://github.com/google/material-design-icons/blob/master/iconfont/MaterialIcons-Regular.ttf and dragged it into https://fontdrop.info/ , and it's revealing 979 ligatures both with "Allow pages to choose their own fonts, instead of your selections above" check and unchecked is that correct?

Can you share the links for a website where the buttons become too large or the text overlaps?

I'm not able to reproduce the overlapping/large buttos in https://material.io/resources/icons/?style=baseline , but I am seeing all buttons displaying text instead of a graphic.

Affected versions
Release 76.0 (64-bit)
Beta 77.0b8 (64-bit)
Firefox Nightly 78.0a1 (2020-05-21) (64-bit)

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to nyanpasu64 from comment #0)

Expected results:

Buttons display icons.

But this is not expected if you've specifically told Firefox not to use the font that the document specifies!

The "Material Icons" webfont doesn't map Unicode codepoints to icons, but instead words to icons (via ligatures). If you disable browser.display.use_document_fonts, Firefox renders the text in sans-serif or serif, instead of "Material Icons".

Yes, that's exactly the problem. The content in question is "normal" English text, and by disabling browser.display.use_document_fonts you've asked Firefox to use the default fonts specified in Preferences, rather than any fonts the website styles might call for.

I think Firefox already has code for detecting Unicode PUA-based icon fonts and using the webfont anyway.

Not exactly... it doesn't "detect PUA-based icon fonts". What happens is that the webfont is still present in the font-family list; what browser.display.use_document_fonts=0 does is to simply put the generic serif or sans-serif at the beginning of the list. But if the content uses PUA codepoints, and those codepoints aren't supported by the default font, then they'll be displayed using the next font in the list.

I don't know if it can be generalized to detect ligature-based icon fonts.

That doesn't work in the Material Icons case because (obviously) the ASCII characters making up the icon names are supported by the default font that is now at the start of the font-family list. And so other fonts in the list (such as the Material Icons webfont) are not even considered.

I don't think there's any reasonable way for Firefox to somehow "know" that even though you've asked it to use the default fonts from Preferences wherever possible, this particular font should be an exception to that. Disabling use_document_fonts is, by its nature, likely to break the rendering of some websites that depend on very specific font choices.

So I don't think this is really a bug; it's the expected result of using an option that disables a key part of the website's styling.

Comment 4

[nyanpasu64]

Attachment: Screenshot of Android developers website with overlapping icon text

Source: https://developer.android.com/reference/android/graphics/Color

Comment 5

[nyanpasu64]

One possible solution is to add a whitelist of font names to let through, populated with "Material Icons" and users can add more fonts via about:config.

(Not related to this bug, but it would be nice to allow custom fonts on Google Docs but no other websites.)

Comment 6

[Vincent Lefevre]

There may be several reasons to use browser.display.use_document_fonts = 0, but one of them (this is my case) is for readability reasons for text, and in this case this should not apply to word-ligature icon fonts. There should be a way to detect such fonts at some level. But the suggested whitelist solution would probably work in practice, and if there is some default, here are the names I could find:

• Material Icons
• Google Material Icons
• Material Symbols Outlined
• Material Symbols Rounded
• Material Symbols Sharp

Matching exact names would probably not be sufficient. A list of patterns could be used (thus allowing to match substrings, e.g. "Material", and in case of false positives, "Material Icons,Material Symbols").

Comment 7

[Pierre Ossman]

Duplicate of bug 1363454 or bug 1521352?

Comment 8

[Daniel Holbert [:dholbert]]

Yeah, let's mark this as a duplicate of bug 1363454.

These are all describing the same core issue, but I think we're using bug 1363454 (per its title) to discuss hypothetical mitigations in Firefox, vs. bug 1521352 to discuss outreach to Google at least to fix their affected sites.