If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Firefox no longer chooses the earliest font in a stylesheet




Layout: Text
5 years ago
5 years ago


(Reporter: Jack Yan, Unassigned)


14 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)



(2 attachments)



5 years ago
Created attachment 644047 [details]
My company home page: note the use of Verdana in the main column. Verdana is the last font family listed in the stylesheet and several of the earlier ones are present.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

Hi there:

I wonder if this is related (https://bugzilla.mozilla.org/show_bug.cgi?id=395866) but that appears to be about Japanese fonts.

I have two sites so far (http://jyanet.com, http://lucire.com/insider) where I have, say, Helvetica, Univers, Verdana listed as the fonts in the stylesheet, in that order. Firefox now (and Chrome and IE9 have done for some time) chooses Verdana, even though it’s not the first in the list. I actually took Verdana out of one of the stylesheets after v. 14 was installed.

My theory is that TTFs are chosen ahead of OTFs, and that Firefox now takes that into account, but it runs counter to the expectations I have when developing the stylesheets.

It might not be a bug given that IE9 and Chrome both do this, but it seems like one to me. And if it isn’t a bug, then how does one now use font face?



Actual results:

Firefox chose the last font listed in a stylesheet rather than the first.

Expected results:

I expected Firefox to choose the fonts from a stylesheet going from first to last, and show the first installed (as it has done since the font face instruction).

Comment 1

5 years ago
Created attachment 644049 [details]
In the centre column, Verdana appears, but it is the last font in the stylesheet.

Comment 2

5 years ago
PS.: Possibly related to this is when Helvetica is chosen as the default font, the UI changes to … Times New Roman.
Component: Style System (CSS) → Layout: Text
Windows doesn't ship with a Helvetica font, AFAIK. Is the Helvetica you have installed perhaps a Type 1 (.pfb) font? I don't think DirectWrite supports legacy Type 1 fonts, so in that case it would be ignored when hardware graphics acceleration is in use on Windows.

Comment 4

5 years ago
Hi Jonathan: great to hear from you. Yes, it is an old Type 1 font, although Firefox is also skipping an OTF (our in-house Lucire 1 font) which is listed as the very first in the stylesheet. I didn’t mention the in-house ones before as no one will have heard of them.
OK, that's why FF (and the other DirectWrite-using browsers) won't see your Helvetica - it's simply not supported.

Difficult to diagnose the issue with your in-house font without being able to examine it hands-on. If you're seeing the same problem with Chrome and/or IE9, that strongly suggests a problem with the font that makes it incompatible with DirectWrite. Does it show up in the menu of available fonts in the Content panel of the FF Options dialog?

Comment 6

5 years ago
Hi Jonathan: yes, the font does show up in the content panel. Everything was fine till this update (presumably because it was this one that DirectWrite came in?).

I know the in-house fonts can appear—if you look at the company home page screen shot, it's there (it's the Helvetica-like sans serif)—just that it doesn't always show up, and Verdana takes its place.

I'm now very curious what could cause them to be skipped—they're pretty ordinary, run-of-the-mill OTFs, but they are "PostScript Type 1 flavoured". Maybe that is the issue?
You need to log in before you can comment on or make changes to this bug.