2

From the MDN :

When a user opened a page using a file:/// URI in Firefox 67 and earlier, the origin of the page was defined as the directory from which the page was opened. Resources in the same directory and its subdirectories were treated as having the same origin for purposes of the CORS same-origin rule.

In response to CVE-2019-11730, Firefox 68 and later define the origin of a page opened using a file:/// URI as unique. Therefore, other resources in the same directory or its subdirectories no longer satisfy the CORS same-origin rule. This new behavior is enabled by default using the privacy.file_unique_origin preference.

Also :

CORS requests may only use the HTTPS URL scheme, but the URL specified by the request is of a different type. This often occurs if the URL specifies a local file, using a file:/// URL.

To fix this problem, simply make sure you use HTTPS URLs when issuing requests involving CORS, such as XMLHttpRequest, Fetch APIs, Web Fonts (@font-face), and WebGL textures, and XSL stylesheets.

The suggestion to "simply make sure you use HTTPS URLs" when using @font-face is fine and all for files that are on a server, but what about HTML files that are supposed to be run locally?

For example, some of the HTML files I work on are used as documentation for Java products. These products are shipped to our customers and our customers are expected to open these HTML files on their laptops and desktops (without running a web server) if they want to learn how to use our products.

The only way I can think of to keep using our Web Fonts (which includes some icon fonts) is to embed the fonts in my CSS files instead of linking them externally.

Are there other options I'm overlooking?

John Slegers
  • 45,213
  • 22
  • 199
  • 169
  • 1
    is local not a relative term to the server? – treyBake Jul 16 '19 at 10:41
  • @treyBake : I replaced "local environments" with "laptops and desktops" if that helps clarify the issue.. – John Slegers Jul 16 '19 at 10:43
  • You could package a simple web server with your documentation — package it as an app that when your customers open the app, it starts up the web server and opens the user’s default web browser to take them to a table of contents or directory page for the documentation. I think that kind of delivery mechanism for the docs is actually pretty common practice for a lot of documentation shops. – sideshowbarker Jul 16 '19 at 10:43
  • @sideshowbarker : We already do that with our frontend web client, as they need this web server to be able to run the samples. For our Java products, however, it doesn't make sense to expect customers to start a web server just to be able to read documentation. – John Slegers Jul 16 '19 at 10:45
  • @JohnSlegers can you not host a documentation site/page somewhere for clients? – treyBake Jul 16 '19 at 10:47
  • 1
    Well, if your product is installed locally, you can also just install the font with it, if the license permits it. That avoids all font-face issues. – Erik A Jul 16 '19 at 10:52
  • @JohnSlegers The point would be that the customers don’t have to manually start a web server. Your app would transparently start it for them without them even needing to know they’ve got a web server running. To them they’re just using the provided documentation app. That’s how a lot of documentation shops deliver their docs — for reasons that include exactly the kind of problem you’re describing here. It’s really sort of a solved problem already: You can package things up in a way that provides a better user experience than making them navigate through doc files directly from the filesystem. – sideshowbarker Jul 16 '19 at 10:53
  • @treyBake : Sure. I do think all of the documentation we ship to our customers is also available on our dev platform. However, that doesn't mean it shouldn't be shipping it with our products. If I buy a physical product, I also prefer a physical manual to come with the product rather than only having an online version of the docs available to me. – John Slegers Jul 16 '19 at 10:53
  • @ErikA : Asking customers to install some fonts just so they can read documentation sounds like a very bad idea to me. – John Slegers Jul 16 '19 at 10:54
  • 1
    @JohnSlegers is that not a preference thing? I mean, I never expect physical manuals anymore.. – treyBake Jul 16 '19 at 10:54
  • @treyBake : Sure... but the whole point of being customer centric is to not force your preference on your customer and to cater to the different needs & preferences of different customers. You may not care about whether or not manuals are shipped with the products you purchase, but that's not a preference you should enforce on paying customers. – John Slegers Jul 16 '19 at 10:57
  • 2
    @JohnSlegers I guess, but I swear nothing does that. All you get nowadays is a health-and-safety thing with a link to the full docs online.. (or at least, for the products I buy). If you want documentation where you have custom fonts, you either need to generate them into PDFs that utilise the font, or just have an online space for it IMO – treyBake Jul 16 '19 at 10:59
  • 2
    Seems like a very weird approach overall btw. Compatibility with local HTML files is hell, if you want to accommodate all browsers including possible future versions for the coming years (since you can't update them without updating the program) and using features like fonts you're going to have lots 'o trouble. Personally, I'd go for an embedded browser to avoid compatibility stuff, some are very lightweight. – Erik A Jul 16 '19 at 11:04
  • @ErikA : Our company has been using this approach for years. And I recently did a rewrite of the docs, experiencing no issues with running the docs locally whatsoever... until I stumbled on this FF68-specific bug. — Do you really think it's weird to run HTML files locally? For me, this seems like the most normal thing to do... I feel old now... – John Slegers Jul 16 '19 at 11:07
  • 1
    Well, I've experimented with it but quickly needed to write browser-dependent code for all major browsers and had future incompatibilities, so stepped off of it. Including an embedded browser comes with a storage cost, but allows more features and gets rid of any and all browser-specific code and future incompatibilities, so I do recommend it. It's also very common, lots of programs noways are largely embedded browsers + websites. Of course, .chm files still work if you want to go really-old-school ;) – Erik A Jul 16 '19 at 11:22
  • Possible duplicates (not sure about the CORS factor): 1. [To use local font in HTML using font face](https://stackoverflow.com/questions/38086083/to-use-local-font-in-html-using-font-face); 2. [@font-face url pointing to local file](https://stackoverflow.com/questions/11812111/font-face-url-pointing-to-local-file) – TylerH Jul 16 '19 at 14:57
  • @TylerH : This issue is caused by a change to FireFox 68 that changes the behavior of `@font-face` when using relative font paths, and which happens only when not using a server. So it can't possibly be a duplicate of questions that were asked long before FF68 was even released ;-) – John Slegers Jul 17 '19 at 12:21
  • @JohnSlegers Well, that's not really true; people have been having this issue with `@font-face` and subdomains falling on the wrong side of Firefox' CORS restrictions (even using file:///) since 2010 *at least*. Anyway, have you tried encoding the font in Base64? – TylerH Jul 17 '19 at 13:54
  • @TylerH : I did not have this issue on my local machine before I upgraded Firefox from 67 to 68. And I'm pretty sure this is the first time in years of generating documentation this way & elaborately testing the output that anyone noticed `@font-face` with a relative path failing when browsing HTML files on our laptop/desktop, without using a web server. In my experience, this is clearly a new, unprecedented issue. Anyway, I did consider embedding the font in CSS as a Base64-encoded string, yes. I already mentioned that in my question, actually. – John Slegers Jul 17 '19 at 16:27
  • @TylerH : (continued) Also, Firefox explicitly pointed out that this issue is caused by a recent change, which causes relative `@font-face` paths to be treated as cross-origin rather than local paths when running an HTML file @ `file:///`. Are you saying this happened before and then they fixed it, only for it to break again? If that's what you're saying, do you have any details on that? If not, then what ARE you saying? – John Slegers Jul 17 '19 at 16:35

1 Answers1

0

Another option: Patience. Firefox 69 fixed this bug, so after updating, @font-face works again.

Pimon
  • 21
  • 2