1634670 - Fonts bundled with the application should be treated as part of the base font set

Status: RESOLVED FIXED

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

Description

[Jonathan Kew [:jfkthame]]

On some platforms (Windows & Linux, and Android although that's a bit of a different case and we don't yet categorize fonts there) we bundle an emoji font with the browser. We should ensure any such bundled fonts are treated as part of the "base" font list, not as user-installed fonts (for the purpose of fingerprinting/visibility).

(We could even give such fonts their own separate visibility class, distinct from the core OS-provided fonts, but at the moment I don't see any reason to do that. As far as the browser is concerned, they're equally "standard" and can be assumed to be always available.)

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1634670 - Fonts bundled with the application should be treated as part of the base font set, not as user-installed fonts. r=jwatt

Comment 2

[Thorin [:thorin]]

Just checking that this would pick up on fonts bundled by desktop Tor Browser, which are always in the same directory as Twemoji Mozilla. TB being "portable" - e.g. Portable\Tor Browser\Browser\fonts

Comment 3

[Jonathan Kew [:jfkthame]]

Provided they're being bundled and loaded in the same way, it should treat them the same; the patch isn't related to specific fonts but to the loading of fonts from an application-provided directory.

Comment 4

[Thorin [:thorin]]

Slightly OT: Does this handle cases when the same font is installed/system and bundled. Also, out of interest, which font is used in this scenario: e.g. fingerprinting specific font versions due to changes in glyphs/codepoints supported. If the system has fontA v1 and we bundled fontA v1.1 - which one "wins"? - TIA

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Simon Mainey from comment #4)

Slightly OT: Does this handle cases when the same font is installed/system and bundled. Also, out of interest, which font is used in this scenario: e.g. fingerprinting specific font versions due to changes in glyphs/codepoints supported. If the system has fontA v1 and we bundled fontA v1.1 - which one "wins"? - TIA

I think that's unrelated to this specific issue, and it'd be best to file a separate bug if it's something we should look into further.

(I suspect the behavior may currently vary between systems, depending on how the platform-specific font management works, but would need to inspect and/or test more deeply to be sure.)

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6e0176befe30
Fonts bundled with the application should be treated as part of the base font set, not as user-installed fonts. r=jwatt

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/6e0176befe30