1714543 - Fonts with non-alphabetical names disappeared from selection dropbox

Status: RESOLVED FIXED

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

Description

[omegw0+6b7qe42vpsal0]

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

Steps to reproduce:

Update from Firefox 88 to Firefox 89.

Actual results:

The font I had selected (with a name in Japanese characters) automatically got changed back to the default font, and neither it nor any other fonts with Japanese characters in their names are available to choose from anymore. The only exception seems to be the "default" font in each category (which happens to be a font with a Japanese name in all of Serif, Sans Serif and Monospaced categories), but even those are strictly only able to be selected through the "Default" option, e.g. MS ゴシック is the default Monospaced font, but I cannot select that font in the Serif or Sans Serif dropboxes.

Expected results:

Fonts should be selectable regardless of the script used in their names (and, presumably, the previously chosen font should have remained as it was, instead of reverting to the default)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Hmm, does switching gfx.e10s.font-list.shared=false in about:config and restarting bring the fonts back?

Comment 3

[omegw0+6b7qe42vpsal0]

Indeed it does! Thank you very much for that workaround.

Comment 4

[Jonathan Kew [:jfkthame]]

Is your Windows display language set to Japanese? Many Japanese fonts have both a Latin-script name (e.g. MS Gothic) and a Japanese name (e.g. ＭＳゴシック), and which one we display in the font menu will depend on the system language.

With the display language set to Japanese in the Win10 Settings app, I do see the expected names in the font list. (Note that names such as ＭＳゴシック appear at the very end of the list, not mixed in with Latin-script fonts like MS Reference or MS UI Gothic, because the "ＭＳ" characters are fullwidth Japanese unicode codepoints, not ASCII letters.)

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Firefox 89 font prefs (with Windows display language = Japanese)

Here's an example of what I see in the Fonts selection dialog, with Japanese font names showing up as expected. Does this not work for you, or am I misunderstanding the issue?

Comment 6

[omegw0+6b7qe42vpsal0]

I have my Windows set to English (United States) (I'd test swapping but I don't have the Japanese language pack installed), with Apps & websites, Regional format and Keyboard set to Japanese. I'm not sure if it has anything to do with those settings, but I am 100% certain the fonts with Japanese font names (such as the ones in your screenshot) did not show up at all with any alternate naming until I switched the shared fonts settings to false. I actually tried manually going through all of them one by one before submitting this bug report, and none of them looked even close to what I was looking for.

My Firefox is in Japanese, and it also brings up "Japanese" as the default target when clicking the "Advanced" button at the fonts settings... just for reference.

Comment 7

[Jonathan Kew [:jfkthame]]

I still can't seem to quite understand the issue here. I downloaded the Japanese version of Firefox 89, and am running in on Win10/en-US. The font names I see for the Japanese fonts in Settings are the English names, so the default serif/sans-serif/monospace fonts are Yu Mincho, Meiryo, and MS Gothic respectively. They're shown that way whether I have the gfx.e10s.font-list.shared pref set to true or false. But they're present, and I can select any of them as desired.

The only case where I see the Japanese names of these fonts is if I set the Windows display language to Japanese; then Firefox respects this and displays the fonts by their localized names. Again, this seems to behave the same regardless of the gfx.e10s.font-list.shared setting.

I feel like there must be some key piece of this that I'm missing...

Comment 8

[Jonathan Kew [:jfkthame]]

Makoto, can you reproduce what the reporter here is describing? I think I must be misunderstanding some detail.

Comment 9

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

Set release status flags based on info from the regressing bug 1694174

Comment 10

[Makoto Kato [:m_kato]]

I cannot reproduce this too on Surface Pro (Windows 10 21H1). I can select MS ゴシック on sans-serif.

Comment 11

[omegw0+6b7qe42vpsal0]

Attachment: Available fonts differing when shared fonts flag on or off

Just wanted to add that this issue reproduces 100% for me if I switch the setting back on, so I can try to provide any further info that might be needed. I attached a screenshot displaying that I'm not just being blind -- the MS Gothic family is just not there at all (other than UI Gothic, which never appears to use a Japanese script period, bypassing the issue)

The only case where I see the Japanese names of these fonts is if I set the Windows display language to Japanese

Perhaps the fact that (for whatever reason) my fonts are in Japanese despite Windows being en-US is what is causing the difference in behaviour? With the new system deciding to actively ignore them, while the old one just rolled with it. Just blindly guessing, though.

Comment 12

[Makoto Kato [:m_kato]]

Ah, I can reproduce this on clean image of Windows 10. I guess that this depends on whether Japanese language pack is installed. When it is installed, this doesn't occurs. If not installed even if Preferred Language in OS settings has Japanese as 1st primary, this seems to be occur.

Comment 13

[Jonathan Kew [:jfkthame]]

Oh, interesting! But... I can't seem to figure out how to get into this state; I can't choose Japanese as the primary language without installing the language pack; even if I explicitly uncheck the "Language Pack" option when adding the Japanese language, it still shows that it is installed. (This is on a Win10 system where Japanese has been installed in the past; I've tried to remove it and then re-add it just as a preferred language but without installing the lang-pack, but can't seem to achieve that.)

Could you attach a screenshot of exactly what the Windows language preferences look like in the state where this issue happens? I'd like to be able to reproduce it and debug further.

Comment 14

[Jonathan Kew [:jfkthame]]

My guess is that something must be failing in gfxDWriteFontList::AppendFamiliesFromCollection in this situation, such that we omit these fonts from the list, but I'm not sure exactly what the failure is.

If I can get my system configured so it will reproduce the failure, I'll look into it; or Makoto, if you are able to debug and see what's going on there, that would also be great.

Comment 15

[omegw0+6b7qe42vpsal0]

Attachment: Windows language settings when bug occurs

I attached my main language settings, I can add any sub-screens that may be relevant if needed. In my case, this system was upgraded to W10 from W7, and I haven't really messed with any language settings since, so it is conceivable that Windows may refuse to let you back into a similar configuration once you change it after the initial upgrade/installation?

Comment 16

[Makoto Kato [:m_kato]]

Could you attach a screenshot of exactly what the Windows language preferences look like in the state where this issue happens? I'd like to be able to reproduce it and debug further.

Same as comment #15.

Note that when adding Japanese in Preferred Languages, "Install language pack" is on as default, so you have to off this. If you have already install it, no way to remove language pack only (I cannot find any ways to remove it only). So you have to create new fresh install image.

omegw0+6b7qe42vpsal0, I have a question. What version of your Windows 10? Old windows 10 can reproduce this, but when I set up Windows 10 21H1 (latest version) today, I cannot reproduce this via same way.

Comment 17

[omegw0+6b7qe42vpsal0]

I checked and I'm on 20H2, which should be the previous one. I'm seemingly all caught up on Windows Update, so I guess the staggered release didn't get to me quite yet.

Comment 18

[Jonathan Kew [:jfkthame]]

Ah, I think this explains why I've been unable to reproduce the problem; my Windows machine is on Insider pre-release builds, so presumably too recent to show the issue.

It sounds like this may really be the result of a Windows bug, which is fixed in the most recent versions; however, it would still be good to work around it if we can. Makoto, are you able to try debugging gfxDWriteFontList::AppendFamiliesFromCollection on a system where the problem reproduces? My guess is that something in there is failing and causing it to skip these font families, but I'm not sure exactly where.

Comment 19

[Jonathan Kew [:jfkthame]]

I've pushed an experimental patch at https://treeherder.mozilla.org/jobs?repo=try&revision=86b8a51b81c89948a3ad264d822f9c20524c39ea with a few speculative changes to try and avoid the risk of omitting some fonts from the list.

omegw0+6b7qe42vpsal0, would you be able to test this version and see if it helps? You can download the .zip archive from https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/TJ1TCcEqQrqAh8Tn2fGN6Q/runs/0/artifacts/public/build/target.zip, extract all the files to a folder, and then just run the version of Firefox found inside. I would be really interested to know if this makes any difference.

Comment 20

[omegw0+6b7qe42vpsal0]

I tried this build, and although I'm not sure if I managed to replicate my FF settings accurately, it seems to "work". It shows the same fonts regardless of shared fonts settings, as far as I can tell, including everything with a Japanese script. In fact, it seems to work better than the current, non-shared version on my system -- it displays a boatload of fonts I have installed, and which I have long wondered why they weren't available to select on Firefox. That being said, I wouldn't know if that behaviour changing is somehow problematic in some other scenario. Works great as far as I'm concerned, though!

Comment 21

[Jonathan Kew [:jfkthame]]

Ohh, that's interesting. On your current "standard" version of Firefox, could you look in about:config and check the setting of layout.css.font-visibility.level. If it's not set to 3, try changing it to 3 and see if that fixes the original problem. Thanks!

Comment 22

[omegw0+6b7qe42vpsal0]

I took a look, but unfortunately it was already at 3.

Comment 23

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1714543 - Handle possible DWrite failures better when enumerating available fonts. r=lsalzman

I haven't been able to reproduce the issue here locally and test this directly, but according to
the reporter a build with this patch works for them.

My guess is that perhaps IDWriteLocalizedStrings::GetLocaleName has been returning a failure result,
causing us to drop the relevant font from the list altogether. We can handle that better by still
including the font, even if we're unsure which name matches the system locale.

This patch also adds a few gfxWarning() messages in places where we really don't expect things
to fail, but if they do, it might help us understand why fonts fail to appear.

Comment 24

[Jonathan Kew [:jfkthame]]

Comment on attachment 9226301 [details]
Bug 1714543 - Handle possible DWrite failures better when enumerating available fonts. r=lsalzman

Beta/Release Uplift Approval Request

• User impact if declined: Fonts with localized names may be missing from the font list in Firefox, depending on language/locale settings and Windows version.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: (Difficult to reproduce, dependent on details of Win10 configuration and language setup; but reporter confirms that tryserver build works for them.)
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Just improves error handling in DirectWrite font enumeration code, so we are less likely to entirely ignore a validly installed font.
• String changes made/needed:

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ff330b601ec3
Handle possible DWrite failures better when enumerating available fonts. r=lsalzman

Comment 26

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/ff330b601ec3

Comment 27

[Julien Cristau [:jcristau]]

Comment on attachment 9226301 [details]
Bug 1714543 - Handle possible DWrite failures better when enumerating available fonts. r=lsalzman

approved for 90.0b7, thanks

Comment 28

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ee17be791c37

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Shared font list was disabled for 89.0.1.