1252821 - [CSS Font Loading] document.fonts.check / FontFaceSet.check returns 'true' for unkown fonts

Status: RESOLVED INVALID

(Core :: DOM: CSS Object Model, defect, P3)

Description

[Zhenguo OU]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

Steps to reproduce:

In Firefox Version 44.0.2
In Chrome Version 48.0.2564.116 (64-bit)

1. Open A tab in both browsers, for example:
https://developer.mozilla.org/en-US/docs/Web/API/FontFaceSet/check

2. Open console and input:
document.fonts.check('italic bold 16px Invalid')


Actual results:

Firefox:
>> document.fonts.check('italic bold 16px Invalid')
<-  true

Chrome:
>> document.fonts.check('italic bold 16px Invalid')
<-  false


Expected results:

Firefox should returns false for invalid font names.

Comment 1

[Zhenguo OU]

Also reproduce on Firefox nightly Version 47.0a1 (2016-03-01).

Comment 2

[Andrew Overholt [:overholt]]

Jet, do you or someone you know what the expected behaviour is here?

Comment 3

[Jet Villegas (inactive)]

We're supposed to return true for that case (see line 1395 in the test:)
https://bugzilla.mozilla.org/attachment.cgi?id=8626775&action=diff 

I believe this was added to prevent fingerprinting attacks. +cc: Cameron to be sure...

Comment 4

[Zhenguo OU]

For this inconsistent behavior, I also create a bug for Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=591602

I think Firefox is following W3C
https://drafts.csswg.org/css-font-loading/#font-face-set-check
"
If font face list is empty, or all fonts in the font face list either have a status attribute of "loaded" or are system fonts, return true. Otherwise, return false.
"

Comment 5

[Zhenguo OU]

But return true for non exist names make the API hard to be used. I use document.fonts.check() to check whether a font name is actually available in the platform, return true for non exist font confuse me.

Comment 6

[Zhenguo OU]

Firefox is following the draft version of standard.
Chrome is following the TR version of standard.

Comment 7

[Tab Atkins Jr.]

No, the correct behavior is to *throw* for non-existent fonts.  I'm not sure how everyone keeps skipping over step 3 in the algorithm.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

I don't see any mention of fingerprinting in bug 1072102 (as comment 3 suggests). We should just revert the logic for now. I'll file a bug to update to follow the spec properly here since it seems other browsers don't do that either.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Ah, so I understand the problem better now. Fixing this would trivially expose the system font list to the web. That's clearly not great.

We could call into gfxPlatform, and get the actual platform name... But that probably requires some discussion and talking with the privacy and security folks first.

Comment 12

[Jonathan Kew [:jfkthame]]

AFAICT, step 3 of the spec "If found faces is false, throw an XXX error and abort this algorithm" means we're supposed to throw an ("XXX"?) error here. Yes, this exposes the set of system fonts; however, as the spec notes, they're also exposed via @font-face so I'm not sure how much this matters.

Chrome returns false rather than true, so it also fails to follow the current spec text, and its behavior makes font-based fingerprinting trivial.

Safari returns true, like Firefox, which the better behavior from a privacy-protection point of view, but does not match what the spec says.

(In https://bugs.chromium.org/p/chromium/issues/detail?id=591602#c7, Tab confirms that Chrome's behavior is wrong, but the bug was later closed "WontFix".)

I've filed https://github.com/w3c/csswg-drafts/issues/5744 to propose removing the spec requirement to throw an error here.

Comment 13

[Arjan Haverkamp]

This issue seems to be back in Firefox 92.0.1.
Try the example made by the original reporter, it will always return true.
Fails in in FF92.0.1 on Windows and MacOS.

Comment 14

[Jonathan Kew [:jfkthame]]

This is the behavior required by the CSS Font Loading spec. It is specifically mentioned in the note there:

Likewise, if none of the specified fonts exist (for example, names are mis-spelled), the method also returns true, because using this font list will not trigger any loads; instead, fallback will occur.