I'm developing a website served using HTTP protocol. In development I use Webpack with it's webpack-dev-server, which serves the page locally on http://localhost:9090
.
I was surprised to see in Firefox 58 console the following mixed content error about loading the font file. It's weird to me, cause the page is served using HTTP not HTTPS and I thought mixed content errors are limited only to HTTPS pages.
`Blocked loading mixed active content “http://localhost:9090/b1aa06d82e70bbd5a14259a94c9bbb40.ttf”
I found out that the source of the error is YouTube video embedded in an <iframe>
on the page (<iframe src="https://www.youtube.com/embed/...>
). As soon as I remove the YouTube embed, the error disappears from the console.
I don't understand this behavior, cause it's not nested HTTPS iframe which is making this font request, but the outer HTTP page (top-level browsing context)!
The outer page (top-level browsing context) is served using HTTP. Only it's embedded iframe is fetched using HTTPS. The HTTP request for a font file that the outer page makes (not the embedded iframe) produces mixed content error in Firefox 58 console.
To give a working example I created 2 pens on Plunker, which is served over HTTP and imports (the Plunker site itself, not my code) WOFF font Font Awesome over HTTP.
The example With error, which has YouTube iframe embedded over HTTPS, produces the following error in Firefox 58 console: Blocked loading mixed active content “http://plnkr.co/css/font/Font-Awesome-More.woff”
.
The example Without error, which is the same code just having the iframe removed, produces no error.
It seems that Firefox caches fonts and tries to execute a request to the cached font by use of the URL the font was originally delivered from. That leads to the mixed content error.
I saw that problem with font awesome fonts when I deployed a web application to the server running HTTPS which I had developed on a local server running HTTP. When requesting the remote site Firefox reports:
Blocked loading mixed active content “http://localhost:8080/fontawesome-webfont.woff2”
That impressed me because there is no request to localhost coded in that web application.
In your example the font is loaded by
http://plnkr.co/css/apps/editor-1.6.1.css
which is url(../font/Font-Awesome-More.woff)
One of the CSS or scripts loaded by the iframe must then try to load that font again maybe using a dynamically constructed URL.
I don't know anything about the font caching strategy implemented in Firefox - maybe they identify the font by its name - but one of the solutions I found for my case is to "Forget About This Site" localhost in the history of Firefox.
A solution for your case could be to switch to HTTPS
I had the same issue. I resolved it by using a relative path instead of an absolute path.
Since my fonts are being called from this CSS "/styles/my.css", and my fonts were located in "/fonts/Open_Sans..."
Before (with FF errors):
@font-face {
font-family: "Open Sans";
src: url("/fonts/Open_Sans/OpenSans-Light.woff2") format("woff2"),
url("/fonts/Open_Sans/OpenSans-Light.woff") format("woff");
font-weight: 300;
}
After (without FF errors):
@font-face {
font-family: "Open Sans";
src: url("../fonts/Open_Sans/OpenSans-Light.woff2") format("woff2"),
url("../fonts/Open_Sans/OpenSans-Light.woff") format("woff");
font-weight: 300;
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With