1434377 - Particular font "Nudista" is displaying clear/invisible

Status: UNCONFIRMED

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

Description

[acidjazz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce:

I tried to use the official Nudista font in FireFox (latest on OSX) in TTF, OTF, and WOFF2.


Actual results:

The font displays completely clear/invisible.  Even inspecting elements in the debuger and hovering over font-family for the example tooltip shows up invisible


Expected results:

I see the font perfectly fine like every other browser I've tested this with, you can witness the bug live here: https://oneconcern.com/

Comment 1

[acidjazz]

Attachment: blank.png

Comment 2

[Gingerbread Man]

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

Invisible text on initial page load, but it appears after pressing F5 to reload.

Comment 3

[acidjazz]

(In reply to Gingerbread Man from comment #2)
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
> Firefox/60.0
> 20180130102929
> 
> Invisible text on initial page load, but it appears after pressing F5 to
> reload.

Yes it's a bit behavioral, you can refresh/clear cache to make it appear temporarily, but it'll then eventually disappear again.

Comment 4

[Jonathan Kew [:jfkthame]]

This seems to be some kind of networking-level failure, rather than graphics-related. If I load the site with Developer Tools open, I can see the two requests for the Nudista font files (regular.ttf and bold.ttf), but they don't seem to get any response at all -- no "200 OK", no failure code, nothing at all. It's like the browser issues the requests for these two resources, but is then left waiting indefinitely for _any_ kind of response.

Those same resources load just fine when Safari requests them, however. Or if I request them with curl.

Moving to Network component, in the hope that someone there might have an idea of what could lead to this behavior.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: network activity shown by DevTools when loading the oneconcern.com site

Note the two requests for font files that don't show _any_ result status.

Comment 6

[acidjazz]

(In reply to Jonathan Kew (:jfkthame) from comment #4)
> This seems to be some kind of networking-level failure, rather than
> graphics-related. If I load the site with Developer Tools open, I can see
> the two requests for the Nudista font files (regular.ttf and bold.ttf), but
> they don't seem to get any response at all -- no "200 OK", no failure code,
> nothing at all. It's like the browser issues the requests for these two
> resources, but is then left waiting indefinitely for _any_ kind of response.
> 
> Those same resources load just fine when Safari requests them, however. Or
> if I request them with curl.
> 
> Moving to Network component, in the hope that someone there might have an
> idea of what could lead to this behavior.

This bug originated as I was writing the site locally, so the files originally were delivered on the same machine.

Comment 7

[acidjazz]

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> Created attachment 8946871 [details]
> network activity shown by DevTools when loading the oneconcern.com site
> 
> Note the two requests for font files that don't show _any_ result status.

Keep refreshing, you'll get 302's 304's, 200's, clear your cache as well

Comment 8

[Jonathan Kew [:jfkthame]]

Hmm, that's interesting. I think the most useful thing here, then, would be a simplified testcase that shows the same problem, without as much surrounding complexity as that live site.

Comment 9

[Honza Bambas (:mayhemer)]

Both channels are canceled at (m-c@7b46ef2ae1412b15ed45e7d2367ca491344729f7) with NS_BINDING_ABORTED:

 	xul.dll!mozilla::net::HttpChannelChild::Cancel(NS_BINDING_ABORTED) Line 2337	C++	Symbols loaded.
        xul.dll!nsFontFaceLoader::Cancel() Line 334
 	xul.dll!mozilla::dom::FontFaceSet::UpdateRules({...}) Line 824	C++	Symbols loaded.
 	xul.dll!nsIDocument::FlushUserFontSet() Line 13159	C++	Symbols loaded.
 	xul.dll!mozilla::PresShell::DoFlushPendingNotifications() Line 4191	C++	Symbols loaded.

Comment 10

[Honza Bambas (:mayhemer)]

Note that this is racing: in debug builds (generally slower) the cancellation happens later (on an already finished  hence 200 is received from the server.

Comment 11

[Jonathan Kew [:jfkthame]]

Interesting. There's a suspicious-looking XXX comment here:

  https://searchfox.org/mozilla-central/rev/c56f656febb1aa58c72b218699e24a76425bd284/layout/style/FontFaceSet.cpp#813-815

which sounds like it could be relevant.

And indeed, if I comment out the "loader->Cancel();" line in the loop there, the issue here seems to be resolved -- but that presumably means that we may sometimes leave obsolete loaders to continue downloading, potentially wasting bandwidth etc. I don't really know much about this code, though; I'd ask :heycam but he's away for now, so :bz, do you have any insight as to how we should handle this better?

Comment 12

[Boris Zbarsky [:bzbarsky]]

We could certainly do the canceling when the FontFace is unlinked, unless the loading process itself keeps it alive.

That said, shouldn't we be restarting loads as needed for FontFaces that actually affect the document?  That is, even if we cancel here, if it's affecting actual text we should presumably restart it at some point...

Comment 13

[Jonathan Kew [:jfkthame]]

And another thing that worries me is that when the FontFace load has been cancelled, we end up displaying the elements as blank rather than getting a fallback font. So yes, there may be more issues going on here.... it would be really useful if we had a cut-down testcase that exhibits similar behavior in a more minimal form.

Comment 14

[acidjazz]

I've tried base64'ing a WOFF2 version of the Nudista font and putting it inline in CSS and the fonts are loading perfectly now, i think that might help prove this is a network-related issue.

Comment 15

[Honza Bambas (:mayhemer)]

(In reply to acidjazz from comment #14)
> I've tried base64'ing a WOFF2 version of the Nudista font and putting it
> inline in CSS and the fonts are loading perfectly now, i think that might
> help prove this is a network-related issue.

The issue is timing-related and not network related.

Comment 16

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P3 ]