Why font-awesome icons are not displayed in Mozilla firefox? [duplicate] - html

Question

I am having an issue with using a font accessed via a relative URL.
#font-face {
font-family: 'ElegantIcons';
src:url('../src_main/fonts/ElegantIcons.eot');
src:url('../src_main/fonts/ElegantIcons.ttf') format('truetype'),
url('../src_main/fonts/ElegantIcons.svg#ElegantIcons') format('svg'),
url('../src_main/fonts/ElegantIcons.woff') format('woff'),
url('../src_main/fonts/ElegantIcons.eot?#iefix') format('embedded-opentype');
font-weight: normal;
font-style: normal;
}
When I access the web page the font doesn't work and in the console I get this:
downloadable font: download failed (font-family: "ElegantIcons" style:normal weight:normal stretch:normal src index:1): status=2147500037
source: file:///...snipped.../src_main/fonts/ElegantIcons.woff # file:///...snipped.../src_poke/fonts-style.css
Accessing the file by copying/pasting the URL into the browser address bar shows that it is the correct URL as I can download the font.

Answer 1

A hat tip to Jonathan Kew's response on a relevant mozilla bugzilla entry:
I believe this is working as designed. AIUI, the issue here is that
for a page loaded from a file:// URI, only files in (or below) the
same directory of the filesystem are considered to be "same origin",
and so putting the font in a different subtree (../font/) means it
will be blocked by security policy restrictions.
You can relax this by setting security.fileuri.strict_origin_policy to
false in about:config, but as this gives the page access to your
entire local filesystem, it's something to be used with caution.
To summarise, the "fix" without re-arranging your files:
Open about:config
Set security.fileuri.strict_origin_policy to false
Beware of the security implications
The best way is, however, to make sure any resources are accessible without going back up the file system first.
Note: the origin policy is calculated based on the html, NOT the css file! So a font file right besides an css file might not work, which is very confusing. (At least this is what I thought was the case with Firefox!)
Follow ups:
eradman comments:
It's the other way around: relative paths are relative to the CSS file.
chrylis responds:
You'd think that, but the actual code in Firefox doesn't seem to agree.

Answer 2

For local file we have to use local()
For external we have to use url()
According to the document https://developer.mozilla.org/en-US/docs/Web/CSS/#font-face
For example
src:local('../src_main/fonts/ElegantIcons.eot');

Answer 3

#CharlesGoodwin #eradman Actually, both statements about the origin seem true except that they probably talk about two different things: same-origin check is based on the originating HTML file, while relative URLs for font faces are resolved relative to the CSS file containing the #font-face rule.
Moreover, originating HTML file is not the file that uses the font. I have the following local file structure.
<base-directory>/index.htm
<base-directory>/ARPLS/toc.htm
<base-directory>/dcommon/css/fonts.css
<base-directory>/dcommon/fonts/myfont.woff
fonts.css references myfont.css via url(../fonts/myfont.woff) and toc.htm reference fonts.css via <link ... href="../dcommon/css/fonts.css">. index.htm has a hyperlink to toc.htm.
Now, I have bookmarked both index.htm and toc.htm. If I use the index.htm bookmark, the font is rendered correctly. If I use the toc.htm bookmark, the font fails to load. I guess this is because myfont.woff is in a sub-directory of the directory containing index.htm but not of the directory containing toc.htm.
Observed in Firefox 38.6.

Answer 4

Try adding this to your web.config
<system.webServer>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="365.00:00:00" />
<remove fileExtension=".woff" />
<remove fileExtension=".woff2" />
<mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />
<mimeMap fileExtension=".woff2" mimeType="application/font-woff2" />
</staticContent>

Answer 5

Usually this happens when the original source css has relative font face declaration like so ../fonts/some-font.woff, and you compile that source CSS into bundle.css which resides at some other path. So that way you lose the path to font.

Answer 6

I have been running into this issue since the latest update (about 1.5 weeks ago). This thread specifically, plus the comments in Bugzilla helped me to understand the problem as a security feature. The solution that I found (eventually) was to take my Firefox preferences off of "strict" security and set to standard/default. "Strict" even says it will break some sites, so I think that this goes to the above point that this issue is by-design.