I am currently developing a website and have trouble showing my font-icons in firefox. every browser except for firefox can load and show my font-icons, but on firefox I get the following error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///C:/Users/Me/Desktop/website/resources/dist/css/fonts/themify.ttf. (Reason: CORS request not http).
the path of the file is correct, as the browser lets me download the file when I enter the above listed URL. Anybody knows why I get this error?
Firefox 68 contains a security patch which restricts the kinds of files that pages can load (and methods of loading) when you open them from a file:// URL. This change was made to prevent exfiltration of valuable data within reach of a local page, as demonstrated in an available exploit. More info: https://developer.mozilla.org/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp
I filed a bug yesterday proposing that fonts be allowed, but it will take time to implement. For now, you can roll back the patch as follows:
In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.
In the search box above the list, type or paste uniq
Double-click the privacy.file_unique_origin preference to switch the value from true to false
Firefox > 106 security.fileuri.strict_origin_policy set false
To mitigate the vulnerability: If you save pages from untrusted sites in a separate folder, e.g., Downloads\Untrusted, then it would be difficult for an attacker to find any valuable content using local file links.
As mentioned in the comment section, I installed a web server. In my case I used tomcat8 and using that I was able to display the icons even in firefox.
The easiest and safe way to overcome the temporary problem (It should be fixed in the next 68.0.2 Firefox update) with web fonts not loaded when previewing locally is to install .ttf or .otf version and link to it in your #font-face declaration. On Windows, go to /Control Panel/Fonts/ and check the exact name of your font, copy to the local('') value.
Example:
#font-face {
font-family: 'Clear Sans';
font-style: normal;
font-weight: 700;
src: local('Clear Sans Bold'),
url('../fonts/woff2-convert/ClearSans-Bold.woff2') format('woff2'),
url('../fonts/WOFF/ClearSans-Bold.woff') format('woff'),
url('../fonts/TTF/ClearSans-Bold.ttf') format('truetype')
}
Related
Still kind of new to fixing website related problems. I found out that after clearing cache in IE 11 and loading my site the Google Fonts is downloading 240 seconds before my webpage is finally loaded. I included image:
Could someone tell me what am I doing wrong please?
Thank you!
IE11 has some issues with Google Fonts, especially fonts over SSL. You can try these solutions:
Web Font Loader: Use the Web Font Loader javascript instead of the default method of adding fonts (CSS way). It provides a common interface to loading fonts regardless of the source, then adds a standard set of events you may use to control the loading experience. The Web Font Loader is able to load fonts from Google Fonts, Typekit, Fonts.com, and Fontdeck, as well as self-hosted web fonts. It is co-developed by Google and Typekit.
Sample usage:
<script src="https://ajax.googleapis.com/ajax/libs/webfont/1.6.26/webfont.js"></script>
<script>
WebFont.load({
google: {
families: ['Droid Sans', 'Droid Serif']
}
});
</script>
If this solution works, you can implement a spesific case just for IE11.
Append style tag: A weird one but it seems to work in some cases.
With the help of jQuery:
$('head').append('<style></style>')
Debug and validate HTML: Third but maybe the most important solution is to check your HTML markup. Parsing errors can cause anything that you can miss. https://validator.w3.org/nu/?doc=https://nutikell.com/ W3 Validator gives 5 errors and a fatal error that you should really fix. As the validator says about fatal error, any browser "Cannot recover after last error. Any further errors will be ignored." That can be IE's problem.
From validation results:
3. [Error]: Element style not allowed as child of element div in this context. (Suppressing further errors from this subtree.)
From line 162, column 5; to line 162, column 11
...
5. [Error]: End tag "a" violates nesting rules.
From line 463, column 3; to line 463, column 89
<a href="https://nutikell.com/nutikellad/nutikell-westyx-king/" class="main-thumbnail">
6. [Fatal Error]: Cannot recover after last error. Any further errors will be ignored.
From line 463, column 3; to line 463, column 89
Browser Plugins: IE plugins like script blockers or ad blockers may also delay loading the font files and cause timeout of the request. Check if you have one.
Max http connections: Each browser has a maximum http connections limit in a single time. Your site, for example, has 21 CSS files which is extremely high. You can see it from Firefox's devtools (F12 > Network Monitor > CSS). Maybe IE11 can't fetch all the CSS files at the same time. You may use a task runner to join/minify your CSS files.
Test in other machines: Check out Browserstack to test in an other machine. If you prefer local dev, Microsoft offers free downloads of virtual machines to test IE with.
EOT and WOFF fonts not loading over HTTPS in IE: An old post can give an idea: We had the same issue with EOT and WOFF fonts in all versions of Internet Explorer (7-11) not loading over HTTPS. After hours of trial and error and comparing our headers with other working sites we found it was the vary header that was messing things up. Unsetting that header for those file types fixed our issue right away.
If your server is Apache this code below would go in the .htaccess file:
<FilesMatch "\.(woff)$">
Header unset Vary
</FilesMatch>
<FilesMatch "\.(eot)$">
Header unset Vary
</FilesMatch>
There are plenty of solutions for this case in that post. You can also check them.
I noticed this info log began to appear in Google Chrome Dev (Version 55.0.2883.18 dev) and I can't imagine why.
Slow network is detected. Fallback font will be used while loading: http://font-path.extension`
It appears on all websites that use font-face, even on local pages and Chrome extensions.
This means the network is slow, and Chrome is replacing a web font (loaded with a #font-face rule) with a local fallback.
By default, the text rendered with a web font is invisible until the font is downloaded (“flash of invisible text”). With this change, the user on a slow network could start reading right when the content is loaded instead of looking into the empty page for several seconds.
Related Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=578029. (A change enabling this behavior for 3G connections landed in September; this should be the reason you got the message.)
Related source code: https://chromium.googlesource.com/chromium/src/third_party/+/master/WebKit/Source/core/css/RemoteFontFaceSource.cpp#74
I faced same issue for chrome build 61.0.3163.100 on MacOs Sierra with localhost as server. Chrome started logging this message when I changed network speed configuration to 3G fast/ 3G slow and again back to Online.
Fix:
When I tried selecting Offline mode and again Online mode, the logging issue disappeared. (This fix may no work on some devices or versions)
Update on 30th Jan 2018
I updated google chrome to Version 64.0.3282.119 (Official Build) (64-bit), it seems this bug is fixed now.
EDIT: This is not working with latest version of 63.0+
I was able to disable it using help from one of above comments, go to
chrome://flags/#enable-webfonts-intervention-v2
The trick is to also disable the "Trigger User Agent Intervention for WebFonts loading always" option just below that as well.
In my case, it was AdBlock Plus extension for Google chrome. Turned it off and it worked perfectly.
if you can access to css of this extension, simply add font-display:block; on font-face definition or send feedback to developer of this extension:)
#font-face {
font-family: ExampleFont;
src: url(/path/to/fonts/examplefont.woff) format('woff'),
url(/path/to/fonts/examplefont.eot) format('eot');
font-weight: 400;
font-style: normal;
font-display: block;
}
I hide this by set console setting
Console settings -> User messages only
Goto chrome://flags/#enable-webfonts-intervention-v2 and set it to disabled
It’s due to a bug in Chrome with their latest API for ‘network speed’. Hope it will be fixed in the next version
I have network throttling disabled but started to get this error today on a 75mb/s business connection...
To fix it in my build of Chrome 60.0.3112.90 (Official Build) (64-bit) I opened the DevTools then navigated to the DevTools Settings then ticked 'Log XMLHttpRequests', unticked 'User messages only' and 'Hide network messages'
I just managed to make the filter regex work: /^((?!Fallback\sfont).)*$/.
Add it to the filter field just above the console and it'll hide all messages containing Fallback font.
You can make it more specific if you want.
If your developing an app that uses google fonts and want to ensure your users do not see these warnings. A possible solution (detailed here) was to load the fonts locally.
I used this solution for an application which at times has slow internet (or no internet access) but still serves pages, This assumes your app uses Google fonts and updates to these fonts are not critical. Also assume that using ttf fonts are appropriate for your application WC3 TTF Font Browser Support.
Here is how I accomplished locally serving fonts:
Go to https://fonts.google.com/ and do a search for your fonts
Add your fonts
Download them
Place them in site root
Add them to your #font file
No, this doesn't mean network is slow.
No, this is not only false warning.
I have this problem on angular web applications after replace link https://fonts.googleapis.com/icon?family=Material+Icons in index.html to integrated version (npm install .... material-icons...). This works, but sometimes web application show that warning.
When warning is shown icons are not rendered for approximately 1 second, so user see badly rendered icons.
I don't have solution yet.
I also had the same errors with fontawesome's fonts.
Then I downloaded the lastest fontawesome's fonts and replace to the old fonts.
And the errors are gone.
The easiest way to disable this is uncheck the warnings in the chrome dev tools
Hope this helps.
you can click 'console settings', and check then box 'Use messages only', after that those messages won't show again.
Updating to the latest version of Chrome (63.0.3239.84) via Help -> About fixed it for me.
(actually, I did had to switch to Offline and back to Online in the Network tab of developers tools to make the last errors go away.)
As soon as I disabled the DuckDuckGo Privacy Essentials plugin it disappeared. Bit annoying as the fonts I was serving was from localhost so shouldn't be anything to do with a slow network connection.
Right mouse сlick on Chrome Dev. Then select filter. And select source of messages.
I've noticed if I use the 'woff' version of the font alone, I got this latency warning message. But if I add the 'ttf' version, the warning disapear. As I'am using a local web application, I made a tradeoff as of the size of font file.
font-face {
font-family: Rakaba;
src: url(../assets/font/web/Rakaba-Bold.woff) format('woff'),
url(../assets/font/Rakaba-Bold.ttf) format('ttf');
}
UPDATE: FIXED, SEE BELOW
Turns out the server I had the font name as 'Close.otf' in my fonts folder and 'close.otf' in my code, I'm guessing my code worked fine locally because it isn't case sensitive, GitHub's server is though apparentely. Just fixed by changing the C from uppercase to lowercase, now the font shows up fine.
...
I am building a website, and for the header I am using a custom font named "close.otf". Now, before pushing my changes to my GitHub Pages repo, I edit my css and html files locally.
So I added the custom font using the #font-face rule on my local CSS file, opened that file up with Chrome, and it shows up completely fine, as you can see:
However, upon pushing the CSS file and HTML file to the GitHub server where my site is hosted, for some reason, upon loading the site in Chrome, the font shows up as follows:
Here is the code I used:
#font-face
{
font-family:"close";
src: url("../fonts/close.otf") format("opentype");
}
And yes, since the local files are a clone of the GitHub repo, it's not some simple mistake like making sure it's in the same folder as the adress etc.
It's also worth noting all other custom fonts I've added to the site have worked completely fine, like the one below the header used in the nav links.
Anyone know how to fix this?
Have you used the developer tools in your browser to see what the server is sending? Your browser is requesting a font file, but the server may be returning forbidden, not found or some other error that will help you troubleshoot.
My MVC4 website uses a .woff font, which is stored locally within my Visual Studio project (RootFolder/Content/font/myfont.woff).
When I debug locally, it works fine (meaning, I can see the desired font).
I then publish to the remote server, test it and the font isn't doing what it should be doing. I can see the relevant text, but with the 'default' font
I logged onto my remote server, and have verified the files are there!
I know the font I'm using is not installed on the server, but that I don't think matters from what I've read.
My CSS is simply
#font-face {
font-family: corsive;
src: url("font/MT.woff") format('woff');
}
h1,h3 {
font-family: 'corsive';
font-size: 1.2em;
}
If I visit mysite.com/content/font/MT.woff then the browser tries to open it.
My site doesn't use SSL, so it's HTTP only.
The same issue persists in FireFox, Chrome and IE
How can I debug this issue?
IIS has security settings that by default deny access to any file extension that has not been defined in MIME types. As the direct link to the font file doesn't seem to work, but causes a 404, this might be the case.
Normally a .woff file extension has no MIME type set, so check the server configuration.
just noticed on several websites that the font awesome icons aren's showing in Google Chrome. The console shows the following error:
Font from origin 'http://cdn.keywest.life' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://www.keywest.life' is therefore not
allowed access.
I found the exact same issue on several other sites. This can be easily fixed by replacing the own CDN reference with:
//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css
-however, this is not the solution, just a workaround. I would love to know the reason and the right solution.
(the cause is this: the website is using it's own CDN, provided by MaxCDN and has the reference to the font awesome fonts and these are not loaded by Chrome, if you are loading the same resource from the Bootstrapcdn resource -mentioned above- it works)
here is a n example of the issue (in the menu and the social icons in footer: http://www.keywestnight.com/fantasy-fest )
Thanks for any help/explanatioon!
Here is the working method to allow access from all domains for webfonts:
# Allow access from all domains for webfonts.
# Alternatively you could only whitelist your
# subdomains like "subdomain.example.com".
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
The problem isn't with the CSS file, it has to do with how the font file is served. The font-awesome.min.css file has lines like
#font-face{font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0')
format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0')
format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0')
format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal}
which cause the browser to request an appropriate font file (eot, woff, ttf or svg) from the same server as the CSS file. This is logical and correct.
However, when the browser requests that font file from cdn.keywest.life, it reads the headers for a Access-Control-Allow-Origin header and doesn't find one so it gives that error message. (This seems like a browser bug to me because it's coming from the same server as the CSS file).
Instead, when you use maxcdn.bootstrapcdn.com the response includes the Access-Control-Allow-Origin:* header and the browser accepts this font file. If your cdn server included this header then it would work too.
If you have an Apache server, see this answer: Font-awesome not properly displaying on Firefox / how to vend via CDN?
This issue of accessing font-awesome assets has been a problem for many people without a comprehensive explanation and resolution to the problem.
What is CORS:
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use. A user agent makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port than the one from which the current document originated.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
The Problem:
The problem stems from how the font-awesome fonts are loaded.
#font-face{
font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal
}
The fonts are loaded via the stylesheet (CSS). The situation we have here is:
The Solution:
While CORS rules have been created on your file storage e.g. S3, and access to the resource has been given to the domain in question, when CDN tries to load the fonts specified in the CSS the origin/domain specified when loading these fonts is that of the CDN but no CORS access has given to the CDN domain.
Create a CORS rule for the CDN domain.
I use a CDN that doesn't allow me to modify its response, so I modified font-awesome.min.css, replacing relative path with absolute path and it worked.
None of the answers worked for me, I had to create an edge rule on maxcnd back office (which change config file on you zone)
More info here
https://www.maxcdn.com/one/tutorial/edge-rules-recipes/
https://www.maxcdn.com/one/tutorial/create-a-rule/
The solution to this is to use another cdn for fontawesome.
https://www.cdnpkg.com/font-awesome/5.11.0
If you're like me and using the official WordPress Font Awesome plugin, you'll want to go into settings and switch from "Use a CDN" to "Use a Kit".