User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

In a folder containing the files for my website, I opened

file:///D:/<redacted>/index.html

which has CSS that loads four WOFF2 font files using relative URLs (file:// URLs).

privacy.file_unique_origin has its default value of true.

Actual results:

As designed, the font file are not loaded, and the Web Console lists messages like the following for each file:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///D:/<redacted>/fonts/opensans.woff2. (Reason: CORS request not http).

This and similar issues are popping up quite a lot in recent days:

• https://support.mozilla.org/questions/1264603 (fonts)
• https://support.mozilla.org/questions/1264596 (frames)
• https://support.mozilla.org/questions/1264400 (fonts)
• https://support.mozilla.org/questions/1264318 (XSL)
• https://support.mozilla.org/questions/1264312 (fonts)
• https://support.mozilla.org/questions/1264299 (fonts)
• https://support.mozilla.org/questions/1264280 (fonts)
• https://www.reddit.com/r/firefox/comments/cc5xoz/css_custom_fonts_broken_in_new_update/ (fonts)
• https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493 (HTML help system)

Expected results:

Font files are unlikely to contain sensitive data, and other kinds of files are unlikely to have a .woff or .woff2 file extension. I think it would make sense to allow an exception to the file_unique_origin treatment for such files to facilitate local web development. This is far preferable to users having to disable this protection completely.

For example, perhaps in nsNetUtil.cpp there could be something along the lines of:

if (!StaticPrefs::privacy_file_unique_origin() || is_permitted_file_type()) {

Then is_permitted_file_type() would return true for .woff and .woff2 files.

(I'm not a C programmer so the details are beyond me.)

[Tracking Requested - why for this release]: See the existing tracking+ bits on bug 1566172

I'm attaching this zip archive that demonstrates a basic use-case we have for our locally deployed help files. When loaded in FireFox, if working correctly, you should see a small car icon.

Thank you.

So in Safari behavior is to just not enforce CORS for @font-face at all, as far as I can tell.

In Chrome behavior is to enforce CORS for the case of file:// linking to an https:// font resource, afaict. I tried digging through their code a bit and haven't found how exactly they implement the behavior; it's possible that this is hitting their LocalFontFaceSource codepath and that that does not do the same-origin check...

For the record, I wasn't intentionally excluding .otf, .ttf or other supported font file formats. Not sure about .svg for fonts.

Looks like font-awesome uses backup font formats for portability. The SVG format is the last one on the list, so I'm not certain you need to enable all the formats for local resources, just the ones that FireFox would need on the platforms it runs on.

Jonathan: given the number of complaints we should fix this and not require CORS for file:// loads. We can't make a blanket CORS exception for file://, the fix will need to be specific to fonts (although it could still be in the CORS code if that knows what kind of request it is). Could you point me where the CORS check is made in the font code?

Baku: is this something you could take on?

I guess you want to start from https://searchfox.org/mozilla-central/rev/22b330ecb3edba1536a54887060cbdd09db21c59/layout/style/FontFaceSet.cpp#581, which is where font loads get kicked off.

We call NS_NewChannelWithTriggeringPrincipal here passing in TYPE_FONT for content policy type, so perhaps that can be propagated down to wherever the decision to relax restrictions for fonts needs to be made?

I take this bug.

https://hg.mozilla.org/mozilla-central/rev/86db1d535ac5

Comment on attachment 9079157 [details]
Bug 1565942 - Allow the loading of TYPE_FONT from file: URLs, r?bzbarsky

Beta/Release Uplift Approval Request

• User impact if declined: file: URLs are not considered cross-origin if the paths are different. It seems this is not good for fonts. This patch allows the loading of fonts, from file: URLs. It's nice to have this patch in beta in order to reduce the number of breakage.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: There is a STR in the description of the bug.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk. It's just related to file: URLs and the loading of fonts.
• String changes made/needed: none

Comment on attachment 9079157 [details]
Bug 1565942 - Allow the loading of TYPE_FONT from file: URLs, r?bzbarsky

Fixes a frequently-reported issue with the file: URI restrictions landed in 68. Approved for 69.0b7.

https://hg.mozilla.org/releases/mozilla-beta/rev/5eb5970cd31d

I have managed to reproduce this issue using Firefox 70.0a1 (BuildId:20190714214027) on Windows 10 64bit with the test files provided in Comment 2.

This issue is verified fixed using Firefox 70.0a1 (BuildId:20190723034754) and Firefox 69.0b7 (BuildId:20190722201635) on Windows 10 64bit, macOS 10.13.6 and Ubuntu 18.04 64bit.

Andrea, we may be spinning a 68.0.2 release soon. Is this something we should consider nominating for release approval to ride along in case?

Comment on attachment 9079157 [details]
Bug 1565942 - Allow the loading of TYPE_FONT from file: URLs, r?bzbarsky

Beta/Release Uplift Approval Request

• User impact if declined: We want to add an exception to our same-origin check for file: URLs, when we load fonts.
  This should land together with the unique file: URLs patch.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See the bug description
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We just use a different security flag for font file URLs.
• String changes made/needed:

Beta/Release Uplift Approval Request

• User impact if declined: We want to add an exception to our same-origin check for file: URLs, when we load fonts.
  This should land together with the unique file: URLs patch.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See the bug description
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We just use a different security flag for font file URLs.
• String changes made/needed:

Beta/Release Uplift Approval Request

• User impact if declined: We want to add an exception to our same-origin check for file: URLs, when we load fonts.
  This should land together with the unique file: URLs patch.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See the bug description
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We just use a different security flag for font file URLs.
• String changes made/needed: none

Comment on attachment 9079157 [details]
Bug 1565942 - Allow the loading of TYPE_FONT from file: URLs, r?bzbarsky

Fixes a commonly-reported regression from CORS changes landed late in the Fx68 cycle. Has baked on Nightly and Beta without any newly-reported issues. Approved for 68.0.2 & 68.0.2esr.

https://hg.mozilla.org/releases/mozilla-release/rev/94b2c630c42c

FIREFOX_ESR_68_0_X_RELBRANCH https://hg.mozilla.org/releases/mozilla-esr68/rev/588f760c7dfa

https://hg.mozilla.org/releases/mozilla-esr68/rev/d6bf3c305aa4

Added to the 68.0.2 relnotes:

Allow fonts to be loaded via file:// URLs when opening a page locally

This issue is verified fixed using Firefox 68.0.1esr (BuildId:20190801112453) and Firefox 68.0.2 (BuildId:20190801110126) on Windows 10 64bit, macOS 10.13.6 and Ubuntu 18.04 64bit.