1565966 - Issues with selecting the Franklin Gothic (Medium) font on Windows using the shared font list [was: The Segoe UI Bold font will fallback to Arial Regular after two minutes of running the browser]

Status: RESOLVED FIXED

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

Description

[blinky]

Attachment: testcase

Steps to reproduce:

1. Set gfx.e10s.font-list.shared to true.
2. Restart Firefox.
3. Open the testcase.
4. Reload the page, if it doesn't change automatically two minutes later after opening the browser.

Actual results:

The Segoe UI Bold font will fallback to Arial Regular after two minutes of running the browser.

Screenshot https://1drv.ms/u/s!AgMN9yoqpWv5i1bs_x96OnQGGxUe

Comment 1

[Jonathan Kew [:jfkthame]]

I don't think that's Arial that it's changing to; it looks more like Franklin Gothic to me. (The Fonts panel in the Element Inspector would be able to verify this.)

There's something weird going on with the Franklin Gothic font, apparently. It looks like DirectWrite may expose it with the font-family name "Franklin Gothic", which is what appears the Fonts control panel list, rather than as "Franklin Gothic Medium", which is what's actually in the name table of the font.

I don't see the family name "Franklin Gothic" anywhere in the name table of the font, and yet DW appears to be coming up with it, and we take that as the "primary" family name; the alternate "Franklin Gothic Medium" isn't recognized until after the deferred font loader task has finished, which on Windows runs 2 minutes after startup. (That's probably much more delay than we really need these days; it originated back when DW was young and we were having some really slow startup issues. Reducing the value of gfx.font_loader.delay would mitigate this.)

Still something funny going on with Franklin Gothic, though; it would be good to understand this better.

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like this isn't preffed on by default so I think we can leave it to jfkthame and remove it from regression triage.

Comment 3

[Jonathan Kew [:jfkthame]]

So after some digging around, it turns out there are two issues here, actually.

First, on Windows the shared font-list's "alias" families don't work properly, because when we instantiate fontEntries from shared font-list Face records in gfxDWriteFontList::CreateFontEntry, we depend on the Family's Index() and IsBundled() values to help us create the proper DWrite face. But we don't keep track of these when collecting family aliases, and so we're liable to end up with the wrong face. We need to add this to the mAliasTable that is used to collect Family aliases, prior to storing them into the shared list.

(On macOS, instantiating the fontEntry doesn't depend on any information from the Family record, so the alias families work fine there.)

The second issue is that in the case of Franklin Gothic, the font's "real" family name (as stored in the 'name' table) is "Franklin Gothic Medium", but DirectWrite munges this via a pretty complex set of heuristics, and ends up exposing the family as "Franklin Gothic". So when the font list is first initialized, we don't recognize the font by its "real" name, only by the DW-munged version. After the deferred font info loader has finished, we will have an alias for the original family name, but it's unfortunate that the original name doesn't work until then, especially given that this is a preinstalled font on Windows.

We can mitigate that while waiting for the deferred loader to complete by adding some heuristics that look for such cases based on stripping the style component off the requested family name, and checking if such a "cleaned-up" family is present in the list from DW. That makes "Franklin Gothic Medium" work immediately on startup, and should fix the testcase here.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1565966 - part 1 - Normalize font family names to lowercase in mAliasTable, for consistency with eventual font-family lookups. r=jwatt

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1565966 - part 2 - Include Family attributes in mAliasTable when collecting font-name aliases, so that fontEntry instantiation on Windows can work correctly for the Aliases eventually stored in the font-list. r=jwatt

Depends on D41242

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1565966 - part 3 - On Windows, make the shared font-list family lookup aware of how DWrite may have stripped a trailing component from the font-family name it exposes. r=jwatt

Depends on D41243

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/277876c31869
part 1 - Normalize font family names to lowercase in mAliasTable, for consistency with eventual font-family lookups. r=jwatt
https://hg.mozilla.org/integration/autoland/rev/6af07e63a001
part 2 - Include Family attributes in mAliasTable when collecting font-name aliases, so that fontEntry instantiation on Windows can work correctly for the Aliases eventually stored in the font-list. r=jwatt
https://hg.mozilla.org/integration/autoland/rev/b260ba66c88f
part 3 - On Windows, make the shared font-list family lookup aware of how DWrite may have stripped a trailing component from the font-family name it exposes. r=jwatt

Comment 8

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/277876c31869
https://hg.mozilla.org/mozilla-central/rev/6af07e63a001
https://hg.mozilla.org/mozilla-central/rev/b260ba66c88f