760436 - Font fails to load from local filesystem Downloadable font: download failed

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[mgalli]

Attachment: tetscase.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

Using CSS to load a font from the local disk. The structure of the testcase ( linked in this bug ) is: 

./subdir/index.html -> uses ../style.css 
./style.css -> links to ./font/fonts.css 
./font/fonts.css -> defines the @font-face { 
  font-family: 'Varela';
  font-style: normal;
  font-weight: normal;
  src: local('Varela'), url('Varela-Regular.woff') format('woff');
} 



Actual results:

It fails —> see console for errors




Expected results:

To work 

Notes: 
---
* it works if you move things to a server 
* it also works if you make all the files in the same root level dir. The placement of the index.html in the ./subdir seems to cause the above behavior. 

Ref: 

Remote test ( works ) : 

http://www.telasocial.com/labs/testcases_mozilla/localfonts/subdir/

Remote file ZIP ( does not work ) : 

http://www.telasocial.com/labs/testcases_mozilla/localfonts/testcase-local-fonts.zip

Remarks: 

* Breaks http://www.mozilla.org/projects/powered-by.html TelaSocial

Comment 1

[Jonathan Kew [:jfkthame]]

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.

Comment 2

[mgalli]

What about a root 

index.html that has an iframe in the sub dir? and all under the root ( sub directory ) but the iframe, in a subdir, loading from ../font?

Comment 3

[mgalli]

I mean: 

index.html -> iframe 
    iframe.html -> 
       ../font/sfuff

Comment 4

[Giorgio Seregni]

Hello,

i have the SAME problem whit a local resources.

I added :
pref("security.fileuri.strict_origin_policy",false);

but the problem persists.

Help! :)

Comment 5

[Jonathan Kew [:jfkthame]]

Open in the web console (from the Tools / Web Developer menu) before loading your page, and then see if there are any error messages related to the font.

Comment 6

[Giorgio Seregni]

yes i have error in my console.

Timestamp: 05/03/13 15:14:26
Error: downloadable font: download failed (font-family: "FontAwesome" style:normal weight:normal stretch:normal src index:1): status=2147500037
source: file:///Users/gio/workspacePHP/iepso/assets/font-awesome/font/fontawesome-webfont.woff
Source File: file:///Users/gio/workspacePHP/iepso/assets/font-awesome/css/font-awesome.css
Line: 0
Source Code:
@font-face {   font-family: "FontAwesome";   font-style: normal;   font-weight: normal;   src: url("../font/fontawesome-webfont.eot?#iefix") format("eot"), url("../font/fontawesome-webfont.woff") format("woff"), url("../font/fontawesome-webfont.ttf") format("truetype"), url("../font/fontawesome-webfont.svg#FontAwesome") format("svg"); }

Comment 7

[Al Thomas]

(In reply to Jonathan Kew (:jfkthame) from comment #1)
> 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.

Mozilla same origin policy is here: https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs

This states it applies to anything that does a same origin check. From the few tests I have done, this policy does not apply to HTML elements:
 - <a href=""></a>
 - <link href="">
 - <img src="">

The CSS @font-face { src: url("") } should be brought in line with the above to allow local copies of sites. At the very least the same origin policy should be applied relative to the CSS file containing the @font-face src reference and not the HTML link href reference.

For some lengthy discussions on same origin policy applied to file:/// see:

Bug 230606 - Tighten the same-origin policy for local files (file: URLs, trusted, security) https://bugzilla.mozilla.org/show_bug.cgi?id=230606

Bug 84128 - Need user-visible message when CheckLoadURI fails (eg, for links to file: urls) https://bugzilla.mozilla.org/show_bug.cgi?id=84128

Comment 8

[happydooby]

This is still an issue for me, in 8/1/2015. A local web application I'm building can't load fontawesome.

Here's the error:

downloadable font: download failed (font-family: "FontAwesome" style:normal weight:normal stretch:normal src index:2): status=2147500037 

http://stackoverflow.com/questions/25865395/cant-load-font-awesome-from-subdirectory

Yet it works fine in chrome.

Comment 9

[John Daggett (:jtd)]

see comment 7

Comment 10

[happydooby]

It is from the same origin, my local filesystem. Its a bug.

Comment 11

[John Daggett (:jtd)]

With the three @font-face definitions below, 

  @font-face {
    font-family: test1;
    src: url(markA.woff);
  }
  
  @font-face {
    font-family: test2;
    src: url(fonts/markB.woff);
  }
  
  @font-face {
    font-family: test3;
    src: url(../fonts/markC.woff);
  }

Firefox allows the first two and denies the last one. This is correct behavior I think.

Chrome denies all three, Safari allows all three.

Comment 12

[happydooby]

Both chrome and safari allow all three, because they are on the local filesystem(and thus the same origin applies).

I've tested with all three, and firefox is the only one that this is broken for.

Comment 13

[John Daggett (:jtd)]

(In reply to happydooby from comment #12)
> Both chrome and safari allow all three, because they are on the local
> filesystem(and thus the same origin applies).

Running with Chrome 46dev all three are denied. Safari does not enforce any sort of same-origin restriction for fonts. Other browsers do which is why you're seeing this problem.

Comment 14

[BaNru]

  @font-face {
    font-family: test3;
    src: url(../fonts/markC.woff);
  }
And other options - all work

Linux-Ubuntu
Chrome 48.0.2564.82 (64-bit) and Opera 37.0.2171.0
Opera 12.16 also works :)
Screen: http://download.g63.ru/ff_bug/test_font.png

In FF 45.0 and 47.0a1 last example does not work

Comment 15

[12Me21.MC]

html file:
<head>
<style>
@font-face {font-family: test; src: url('test.otf');}
p {font-family: "test";}
</style>
</head>

<body>
<p>stop lying</p>
</body>

Both the .html file and .otf file are located in the same folder.
This works on Chrome, but not Firefox.
Please actually try it before denying it.
There is no security issue here, it is a bug.

Comment 16

[12Me21.MC]

Attachment: very simple example of the bug

Try denying the existence of this bug NOW!

Comment 17

[Jonathan Kew [:jfkthame]]

I tried the example from attachment 8739695 [details], and it works fine for me (i.e. the font loads and is used to display the sample paragraph) in both Firefox 45.0.1 (current release version) and the latest Nightly 48.0a1 (2016-04-09).

Comment 18

[12Me21.MC]

Attachment: Screenshot of the bug

Comparison of the same html file in Chrome and Firefox. The font does not load correctly in Firefox

Comment 19

[Jonathan Kew [:jfkthame]]

To repeat: your example loads fine for me. So it seems possible there's something about your particular setup that is affecting it.

Have you tried running Firefox with a fresh profile, to eliminate any modified preferences, add-ons, etc., that you might have? And/or try restarting in Safe Mode (go to about:support, click Restart with Add-ons Disabled).

Comment 20

[Shan]

This problem had been bugging me for a while (pun not intended)
Tried MANY solutions and no prevail.
In the end, it was actually caused by adblock plus. At least for my case.

Comment 21

[barney.gale]

We're also seeing this issue in a local Sphinx project. The directory tree looks roughly like this:

.
|-- index.html
|-- static
|   |-- images
|   |   `-- title.png
|   |-- fonts
|   |   `-- opensans.ttf
|   `-- stylesheet.css
`-- subdir
    `-- subindex.html

Both index.html and subindex.html reference "static/images/title.png" and "static/stylesheet.css". For subindex.html, these links move up a directory first, like "../static/stylesheet.css". The stylesheet references "fonts/opensans.ttf". 

What we're seeing:

* When you File > Open File... > index.html, everything works
* When you File > Open File... > index.html, then navigate to subindex.html via a link on index.html, everything works
* When you File > Open File... > subindex.html, images and stylesheets work fine, but the fonts do not.

So it seems like font loading is following a stricter same-origin policy than other resources, like images and stylesheets. I'm guessing the font files need to live somewhere under the base directory of the current file for things to work, but this is a pretty annoying requirement. 

Tested on Firefox 45.1.1

Comment 22

[Philippe]

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> To repeat: your example loads fine for me. So it seems possible there's
> something about your particular setup that is affecting it.
> 
> Have you tried running Firefox with a fresh profile, to eliminate any
> modified preferences, add-ons, etc., that you might have? And/or try
> restarting in Safe Mode (go to about:support, click Restart with Add-ons
> Disabled).

I believe that the RESOLVED INVALID is inadequate, please reopen.

Same problem after a restart in Safe Mode...

With the css:
@font-face {
	font-family: Pecita;
	src: url("../i/Pecita.otf") format("opentype");
}
@font-face {
	font-family: Gentium;
	src: url("./GenR102.ttf") format("truetype");
}
The font Gentium is loaded but not the font Pecita:
downloadable font: download failed (font-family: "Pecita" style:normal weight:normal stretch:normal src index:0): status=2147500037 source: file:///home/philippe/sitesWeb/pecita.net/i/Pecita.otf

Troubleshooting Information:
Application Basics
------------------

Name: Firefox
Version: 45.2.0
Build ID: 20160607223741
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Multiprocess Windows: 0/1 (default: false)
Safe Mode: true

Extensions
----------

Name: Firefox Hello Beta
Version: 1.1.14
Enabled: true
ID: [e-mail]

Name: Adblock Plus
Version: 2.6.6
Enabled: false
ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

Name: Video DownloadHelper
Version: 5.6.1
Enabled: false
ID: {b9db16a4-6edc-47ec-a1f4-b86292ed211d}

Graphics
--------

Adapter Description: X.Org -- Gallium 0.4 on AMD CAICOS
Asynchronous Pan/Zoom: none
Device ID: Gallium 0.4 on AMD CAICOS
Driver Version: 3.0 Mesa 10.3.2
GPU Accelerated Windows: 0/1 Basic (OMTC)
Supports Hardware H264 Decoding: No;
Vendor ID: X.Org
windowLayerManagerRemote: true
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0
CairoUseXRender: 1

Important Modified Preferences
------------------------------

accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.hashstats_reported: 1
browser.cache.disk.smart_size.first_run: false
browser.cache.frecency_experiment: 2
browser.download.importedFromSqlite: true
browser.places.smartBookmarksVersion: 7
browser.sessionstore.upgradeBackup.latestBuildID: 20160607223741
browser.startup.homepage: http://pecita.net/
browser.startup.homepage_override.buildID: 20160607223741
browser.startup.homepage_override.mstone: 45.2.0
browser.tabs.warnOnClose: false
dom.apps.reset-permissions: true
dom.mozApps.used: true
extensions.lastAppVersion: 45.2.0
font.internaluseonly.changed: true
gfx.crash-guard.glcontext.appVersion: 45.2.0
gfx.crash-guard.glcontext.deviceID: Gallium 0.4 on AMD CAICOS
gfx.crash-guard.glcontext.driverVersion: 3.0 Mesa 10.3.2
gfx.crash-guard.status.glcontext: 2
media.gmp-manager.buildID: 20160607223741
media.webrtc.debug.aec_log_dir: /tmp
media.webrtc.debug.log_file: /tmp/WebRTC.log
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1469770862
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
print.print_bgcolor: false
print.print_bgimages: false
print.print_duplex: 0
print.print_evenpages: true
print.print_in_color: true
print.print_margin_bottom: 0.5
print.print_margin_left: 0.5
print.print_margin_right: 0.5
print.print_margin_top: 0.5
print.print_oddpages: true
print.print_orientation: 1
print.print_page_delay: 50
print.print_paper_data: 0
print.print_paper_height: 11,69
print.print_paper_name: iso_a4
print.print_paper_size_type: 1
print.print_paper_size_unit: 0
print.print_paper_width: 8,27
print.print_scaling: 0,75
print.print_shrink_to_fit: false
print.print_to_file: false
print.print_unwriteable_margin_bottom: 56
print.print_unwriteable_margin_left: 25
print.print_unwriteable_margin_right: 25
print.print_unwriteable_margin_top: 25
privacy.donottrackheader.enabled: true
privacy.sanitize.migrateFx3Prefs: true
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1469118894

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.12
Version in use: 4.12

NSS
Expected minimum version: 3.21.1 Basic ECC
Version in use: 3.21.1 Basic ECC

NSSSMIME
Expected minimum version: 3.21.1 Basic ECC
Version in use: 3.21.1 Basic ECC

NSSSSL
Expected minimum version: 3.21.1 Basic ECC
Version in use: 3.21.1 Basic ECC

NSSUTIL
Expected minimum version: 3.21.1
Version in use: 3.21.1

Experimental Features
---------------------

Sandbox
-------

Seccomp-BPF (System Call Filtering): true
Seccomp Thread Synchronization: false
User Namespaces for privileged processes: true
User Namespaces: false
Media Plugin Sandboxing: true

Comment 23

[Jonathan Kew [:jfkthame]]

(In reply to Philippe from comment #22)
> With the css:
> @font-face {
> 	font-family: Pecita;
> 	src: url("../i/Pecita.otf") format("opentype");
> }
> @font-face {
> 	font-family: Gentium;
> 	src: url("./GenR102.ttf") format("truetype");
> }
> The font Gentium is loaded but not the font Pecita:
> downloadable font: download failed (font-family: "Pecita" style:normal
> weight:normal stretch:normal src index:0): status=2147500037 source:
> file:///home/philippe/sitesWeb/pecita.net/i/Pecita.otf

I believe that is behaving as expected. By default, only files in or under the same directory are considered same-origin for "file:" URLs, so your "../i/Pecita.otf" is not allowed to load.

(You can relax this requirement by setting "security.fileuri.strict_origin_policy" to false in about:config.)

Comment 24

[Philippe]

(In reply to Jonathan Kew (:jfkthame) from comment #23)
> (In reply to Philippe from comment #22)
> > With the css:
> > @font-face {
> > 	font-family: Pecita;
> > 	src: url("../i/Pecita.otf") format("opentype");
> > }
> > @font-face {
> > 	font-family: Gentium;
> > 	src: url("./GenR102.ttf") format("truetype");
> > }
> > The font Gentium is loaded but not the font Pecita:
> > downloadable font: download failed (font-family: "Pecita" style:normal
> > weight:normal stretch:normal src index:0): status=2147500037 source:
> > file:///home/philippe/sitesWeb/pecita.net/i/Pecita.otf
> 
> I believe that is behaving as expected. By default, only files in or under
> the same directory are considered same-origin for "file:" URLs, so your
> "../i/Pecita.otf" is not allowed to load.
> 
> (You can relax this requirement by setting
> "security.fileuri.strict_origin_policy" to false in about:config.)

It's correct, TY :-)

Comment 25

[Mathias.Z]

This problem occurs also when using bootstrap with personalized tree stucture.
Download of fonts/glyphicons-halflings-regular.* referred by bootstrap.min.css fails.
Setting "security.fileuri.strict_origin_policy" to false solves it in my case with FF version 40.0.3
Thanks to Jonathan Kew

Comment 26

[Alfredo Fernández Díaz]

I think this is a perfectly valid bug, still unresolved in FireFox 45.7.0; I'm attaching what I believe is a better testcase:

.
|-- testdn1.htm
|-- testdn2.htm
|-- folder
|   |-- testup1.htm
|   `-- testup2.htm
|-- cssaux
|   |-- watermark.png
|  `-- Valen70.ttf
`-- css
    |-- test1.css
    |-- test2.css
    `-- cssaux (duplicate of above)
        |-- watermark.png
        `-- Valen70.ttf

testdn1.htm loads css/test1.css OK, then test1.css loads watermark.png and Valen70.ttf from cssaux/ --> fine, everyone is going 'down'.

folder/testup1.htm loads ../css/test1.css OK, then test1.css tries to load watermark.png and Valen70.ttf from cssaux/ --> watermark.png. Background loads, font doesn't, yet they're both 'up' for CSS.

testdn2.htm loads css/test2.css OK, then test2.css loads watermark.png and Valen70.ttf from ../cssaux/ --> html is going 'down', css is going up -- yet BOTH background and font load OK.

folder/testup2.htm loads ../css/test2.css OK, then test2.css tries to load watermark.png and Valen70.ttf from ../cssaux/ --> watermark.png. Background loads, font doesn't.

So the 'same origin' policy is stricter for fonts than it is for other files.

Comment 27

[Alfredo Fernández Díaz]

> folder/testup1.htm loads ../css/test1.css OK, then test1.css tries to load
> watermark.png and Valen70.ttf from cssaux/ --> watermark.png. Background
> loads, font doesn't, yet they're both 'up' for CSS.

Meant to read "both 'up' for HTML".

Comment 28

[Alfredo Fernández Díaz]

Attachment: Compare: 2 HTML files load BG/FONT from down in the filesys, two more load from higher in the filesys tree

Comment 30

[RobertZimmerman]

The wide range of fonts are created to target market needs and provide designers with sophisticated font choices, thanks.