STEPS TO REPRODUCE:

1. Download https://mdn.mozillademos.org/files/7775/webfont-sample.html to a file named "test.html" on local disc.
2. Download https://mdn.mozillademos.org/files/2468/VeraSeBd.ttf to a file named "test.ttf" in the same directory.
3. Edit "test.html" so the CSS url() bit says url("test.ttf")
4. Load "test.html" in Firefox.

EXPECTED RESULTS: The text is bold like is is on https://mdn.mozillademos.org/files/7775/webfont-sample.html

ACTUAL RESULTS: The text is not bold.

ADDITIONAL INFORMATION:

• In Firefox 67, this worked as long as the font file was a sibling, or under a sibling, of the HTML (or CSS?) file, due to the way our same-origin policy worked. It did not work if the font was a child of some unrelated or ancestor dir (e.g. if the font file is placed in /tmp and the HTML in ~, it does not work in 67).
• In Firefox 68, this does not work due to the changes in bug 1558299
• I just tested Chrome and Safari, and they allow linking from any file:// to any other file:// for fonts, afaict. Presumably a legacy of them not doing CORS enforcement at all for web fonts? (Or do they still not do CORS enforcement there?)

Anyway, this is causing compat issues; see bug 1500453 comment 14.

I had assumed we had audited all consumers of SEC_REQUIRE_SAME_ORIGIN* and SEC_REQUIRE_CORS* in bug 1558299 to see how other browsers behave for them for file:// URLS, but apparently not. Those consumers are:

• SVG external resources
• fetch()
• HTML <track> elements
• font-face rules (this bug)
• <a ping> bits
• Service worker script cache bits of some sort
• DOM workers
• XMLDocument.load (not supported in other browsers, iirc)
• Offline cache manifests
• EventSource
• Navigator.sendBeacon
• HTML media elements with crossorigin attr set
• ChannelMediaResource
• HTML <script> elements with crossorigin attr set
• Module scripts
• Various XSLT stuff (maybe not supported in other browsers?)
• Stylesheet linking elements with crossorigin attr set
• Various image-loading element with crossorigin attr set

OK, looks like bug 1565942 tracks the file:// thing already. Mutating this to cover auditing the rest of the list.

broken xslt stuff got reported a number of times after the 68 release (bug 1565261 and dupes)

• HTML <script> elements with crossorigin attr set: No CORS. No loading. Same on other browsers.
• Module scripts: Basically impossible to test...
• fetch(): No CORS: The requests fail. Same on other browsers.
• <a ping> bits: No CORS. Ping attribute fails the loading. What's the point of loading a file: URLs, btw?
• Service worker script cache bits of some sort: Not interesting. ServiceWorkers are exposed just for http and https.
• DOM workers: No CORS supported here. DOM Workers are basically disabled for file: URLs. Tested in other browsers.
• EventSource: Basically disabled. No CORS supported. Tested in other browsers.
• Navigator.sendBeacon: Exposed just for http/https. Same on other browsers.
• HTML media elements with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.
• Various image-loading element with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.
• XMLDocument.load (not supported in other browsers, iirc): Untested.
• Various XSLT stuff (maybe not supported in other browsers?): Untested.
• ChannelMediaResource: Not an issue. We use FileMediaResource if the channel implements nsIFileChannel: https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/dom/media/BaseMediaResource.cpp#49-50
• HTML <track> elements: We don't load the media element... this cannot be tested.
• Offline cache manifests: Only for HTTPS...
• Stylesheet linking elements with crossorigin attr set: This works in firefox and in other browsers...
• SVG external resources: Blocked by CORS. Same for other browsers.
• font-face rules (this bug): This bug...

• Various XSLT stuff (maybe not supported in other browsers?): No CORS. Similar to other browsers.

See also bug 1565509

Module scripts: Basically impossible to test...

Why can't this work as a test, loaded from file:/// ?

  <script type="module">
    import "./test.js";
  </script>

What's the point of loading a file: URLs, btw?

Probably none. I was just going through the tree listing all the places that do CORS-only or same-origin-only loads.

HTML media elements with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.
Various image-loading element with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.

OK, so these don't get loaded in both Firefox and other browsers? Or does get loaded? For <script> you said it does not get loaded?

Stylesheet linking elements with crossorigin attr set: This works in firefox and in other browsers...

I don't think it works (in the sense of being loaded) in Firefox, on trunk. Testcase, with test.css containing * { color: green}:

<link rel="stylesheet" crossorigin href="test.css">
Is this green?

Looks like this does not load in other browsers either.

SVG external resources: Blocked by CORS. Same for other browsers.

Those don't use CORS at all that I am aware of... They're just restricted to same-origin.

Various XSLT stuff (maybe not supported in other browsers?): No CORS. Similar to other browsers.

It's not CORS; it's restricted to same-origin, right? Does it load in other browsers, or not? That is, what is the right disposition for bug 1565261 and its duplicates?

Ah, I guess bug 1565261 says the XSLT case does not work in other browsers. Amazing how many duplicates we have from people who only did that in Firefox....

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #9)

Ah, I guess bug 1565261 says the XSLT case does not work in other browsers. Amazing how many duplicates we have from people who only did that in Firefox....

IE 11 and Edge on Windows do load and apply an XSLT stylesheet referenced via xml-stylesheet in an XML documents loaded from the local file system if the stylesheet is also on the local file system.

Module scripts: Basically impossible to test...
Why can't this work as a test, loaded from file:/// ?

oh! right. I was thinking about 'import' module directive, and because a script cannot be loaded, 'import' doesn't run.

  <script type="module">
    import "./test.js";
  </script>

This is handled by the same ScriptLoader component. It behaves like a 'script' loading and it's not supported because of CORS.

Stylesheet linking elements with crossorigin attr set: This works in firefox and in other browsers...

Correct: it doesn't work with 'crossorigin' attr set. Without it works. And I confirm we have the same behavior of chrome.

Various XSLT stuff (maybe not supported in other browsers?): No CORS. Similar to other browsers.
It's not CORS; it's restricted to same-origin, right? Does it load in other browsers, or not? That is, what is the right disposition for bug 1565261 and its duplicates?

Correct. And XSLT do not apply on file: URLs in firefox. And in Chrome too. Both block the loading of the XSLT resources.

IE 11 and Edge on Windows do load and apply an XSLT stylesheet

Does that include Chromium-based Edge?

Anyway, it sounds like bug 1565942 definitely needs fixing, bug 1565261 is likely wontfix (though it sure has a lot of dups), and we need to sort out what to do with bug 1565509. I had missed the bug 1565509 codepath in my audit because I had not noticed that CSS images can end up doing CORS....

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #12)

IE 11 and Edge on Windows do load and apply an XSLT stylesheet

Does that include Chromium-based Edge?

Sorry, I haven't used that so far, the tested version is Microsoft Edge 44.18362.1.0/Microsoft EdgeHTML 18.18362 on Windows 10 1903.

Keywords: site-compat

dubious, we're talking about local file:// urls which are by definition NOT sites on the web. "DevAdvocacy" maybe? We don't seem to have a "tool-compat".

Yeah, technically it’s not site compatibility but I’ve already documented this: https://www.fxsitecompat.dev/en-CA/docs/2019/local-files-are-now-each-given-a-different-origin/ (will add more examples as mentioned in Comment 5)

I think we can close this bug. The only open issue was about font, fixed with bug 1565942. For XSLT we have a separate bug too.
bz, are you OK with closing this?

Yep.