Firefox @font-face with local file - downloadable font: download failed

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.

Solution 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.

Solution 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');

Solution 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.

Comments

[J86]

I tried your suggestion, and I still get the error. Also, I moved the awesome-font files to the same directory as the css, and I still get the issue. :(

[Charles Goodwin]

Perhaps you can post a new question and link it here, so I can see how you are doing things?

[Peter Rowell]

@CharlesGoodwin: a seriously Big Thank You®!!! I was going nuts on this, and this was exactly the fix I needed for displaying a page than had been fetched by wget with --page-requisites. You rock!

[dube]

@Ciwan note that 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.

[thouliha]

This is still an issue for me. It works fine on chrome :( .

[eradman]

It's the other way around: relative paths are relative to the CSS file. w3.org/TR/REC-CSS1/#url

[chrylis -cautiouslyoptimistic-]

@eradman You'd think that, but the actual code in Firefox doesn't seem to agree.

[paddotk]

What's the point in changing your settings in Firefox? You want the visitors of your website to see the right fonts, and can't expect them to change their browser settings first.

[paddotk]

Also, importing the fonts relative to either the css file or the html file both don't work. Not in FF nor Chrome.

[Charles Goodwin]

@poepje you don't seem to understand that this is about local HTML/CSS i.e. web development, not a publicly open website.

[paddotk]

@CharlesGoodwin I do, but isn't the idea of a website that it's going to be published on the web eventually? You already have the fonts, so I wouldn't know why you would want to use @font-face for yourself?

[Admin]

Still an issue in 2019. This question doesn't rank very well for the question, but it's the way to go.

[Janus Bahs Jacquet]

This only applies if the local machine is both the server and the client. Once a website is hosted on a server and requested by a different machine as the client, local() refers exclusively to the client machine, over which the website cannot expect to have any kind of control. local() should only be used in conjunction with src(), in order to allow for a locally installed font to take precedence over (or act as a fallback to) a webfont.