1449964 - Unchecking "Allow pages to choose their own fonts, instead of your selections above" does not work on emojis

Status: REOPENED

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

Description

[fearinahandfulofsand]

Attachment: example.png

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180315233128

Steps to reproduce:

Segoe UI Symbol is a font which only has black/white characters. Segoe UI Emoji has coloured characters. Both are system fonts on Windows 8 (and cannot be deleted). I'm trying to get rid of coloured emojis on Firefox.

1. Uncheck "Allow pages to choose their own fonts, instead of your selections above" in Options > General > Fonts and Colours > Advanced (browser.display.use_document_fonts)
2. Set font.name-list.emoji to Segoe UI Symbol
3. Delete fonts\EmojiOneMozilla.ttf
4. Visit https://emojipedia.org/people/


Actual results:

emojipedia.org styles emoji characters with the Segoe UI Emoji font.

Most characters are displayed using Segoe UI Emoji.

Some of the emojis are displayed in Segoe UI Symbol, I believe because they're not present in Segoe UI Emoji and it uses the default Segoe UI Symbol instead. Some characters are displayed as boxes because they are not in either font.


Expected results:

All the emojis should have used the Segoe UI Symbol font, because I turned off the setting that allowed pages to use custom fonts.

I'd also be happy if rather than using Segoe UI Symbol, I could just not use a font at all.

Bug 789788 is related and seems to be a mistake. There's no way to disable the coloured emoji fonts in Firefox on Windows.

It's unintuitive for this setting to not affect even the octicons font. Another user could specifically want to disable that font, and expect this setting did what it says it does.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
20180329100042

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to fearinahandfulofsand from comment #0)
> Expected results:
> 
> All the emojis should have used the Segoe UI Symbol font, because I turned
> off the setting that allowed pages to use custom fonts.

Are all the emojis actually supported by Segoe UI Symbol? From a quick look in Character Map I don't see them. In which case specifying it for font.name-list.emoji won't achieve very much, we'll still fall back to whatever's next in the font list.

Turning off "Allow pages to choose their own fonts..." does not completely disable any fonts, it just promotes the browser's default (serif or sans-serif, as selected in Preferences) to the front of the font-family list so that it will be used ahead of anything specified by the page. But if there are characters that are not supported by whatever fonts you have configured as the default, then other fonts (from the page's font-family list, or from system-wide fallback) will still be used.

Comment 3

[fearinahandfulofsand]

You're right, Segoe UI Symbol is taking priority. I misinterpreted what happened, of course Segoe UI Emoji would have smiling face defined. I guess I will find a font I prefer with more characters then.

Thanks for your time.

Comment 4

[Gingerbread Man]

Attachment: monochrome_emoji.png

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Are all the emojis actually supported by Segoe UI Symbol?

Have a look at this screenshot. As you can see, black and white emoji on the web page, and Inspector reports Segoe UI Symbol and nothing else used for the respective span element.

This is how my normal profile behaves, with "…choose their own fonts" enabled. I don't know how to replicate the result. I tried the same font.name-list.emoji and font.*.x-unicode preferences in another profile, but it still resulted in Segoe UI Emoji being used.

NI again to double-check if you think there's something to address here.

Comment 5

[Jonathan Kew [:jfkthame]]

Interesting - so it looks like Segoe UI Symbol does provide (b/w) glyphs for a bunch of emojis. (I wonder if that's true in all versions, or if there are various configurations out there?)

In that case I think disabling "choose own fonts" should have worked as the reporter intended. Re-opening this to look into it further.

Comment 6

[Jonathan Kew [:jfkthame]]

OK, on thinking about it I believe this is expected, given how the option is implemented. When "choose own fonts" is unselected, the browser's default CSS generic (either 'serif' or 'sans-serif', as selected in preferences) is prefixed to the font list from CSS, so that the user's chosen default (per language/writing system, as configured in prefs) will be used ahead of page-specified fonts.

But that doesn't typically cover emojis, so for those after trying the default font we'll still go through the page's font list, before eventually reaching prefs-fallback, which is where font.name-list.emoji would apply. So if the page explicitly names emoji fonts those will still win over the pref setting.

Probably it would be better, when "allow page to choose own fonts" is unselected, to move the prefs-font-fallback code in front of the rest of the font-family list, so that if the default font doesn't provide the character, our next option is to try other fonts from prefs.

Comment 8

[Daniel Holbert [:dholbert]]

Note: bug 1521352 is a case of something like this with Google's "Material Icons Extended" font [1] which apparently renders strings like "star_border" as a star-with-a-border icon.

So, not strictly emoji, but still an instance of an "icon font" which, when it's blocked via unchecking this "Allow pages..." config option, produces a page that looks pretty broken. To address that, I wonder if we should have an [optional?] escape-hatch from this option to allow fonts with "icon" in the name, or something like that, if that's even feasible.

[1] https://fonts.gstatic.com/s/materialiconsextended/v46/kJEjBvgX7BgnkSrUwT8UnLVc38YydejYY-oE_LvJ.woff2

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #8)

Note: bug 1521352 is a case of something like this with Google's "Material Icons Extended" font [1] which apparently renders strings like "star_border" as a star-with-a-border icon.

So, not strictly emoji, but still an instance of an "icon font" which, when it's blocked via unchecking this "Allow pages..." config option, produces a page that looks pretty broken. To address that, I wonder if we should have an [optional?] escape-hatch from this option to allow fonts with "icon" in the name, or something like that, if that's even feasible.

We could do that, I think, by hacking some extra logic into nsLayoutUtils::FixupNoneGeneric where the useDocumentFonts flag is handled: we could check whether the first font-family name in the list includes "icon", and force useDocumentFonts true in that case even if the user pref is off.

That's a bit of a blunt instrument, though: it would mean that if the document uses a list such as

font-family: "My Icons", "My Text Font", sans-serif;

not only would we activate the icon font (as desired) but also the text font (unwanted) that's in the same list.

So something more sophisticated would be needed; maybe the appropriate logic would be that after calling PrioritizeFirstGeneric or PrependGeneric on the fontlist, we'd then pull any font-family names containing "icon" to the front of the list so that they take priority over the generic.

This all seems pretty hacky, though, for something that isn't really a bug: the browser is doing exactly what the author and user have (unintentionally!) conspired to request. And special-casing font family names that happen to contain a certain 4-letter substring seems rather arbitrary. (All it takes is someone to use font-family: MySemiCondensedFont and suddenly it'd be immune from the useDocumentFonts setting.)

Comment 10

[Daniel Holbert [:dholbert]]

You're right, that sounds like it could end up pretty imprecise/terrible. I retract comment 8 - let's disregard custom icon fonts for the purposes of this bug, and return it to being about emoji which have a better standardized rough expected rendering.

I morphed the Google News bug 1521352 into a tech evang issue, since it's reproducible in Chrome as well (with a special command-line flag).