http://fiddle.jshell.net/JamesKyle/TKhq8/show/light/
If you view this page you can see that I used a Font-Squirrel-Generated #font-face for Franchise it seems to work in every browser except Firefox, any ideas as to why this is?
PS I have looked around and still am not finding an answer
You're linking to a font that's on a different host and doesn't send the right CORS headers. See https://developer.mozilla.org/En/HTTP_access_control and http://www.fontsquirrel.com/blog/2010/11/troubleshooting-font-face-problems
Related
I have went through numerous posts about this and still can't get an answer. I created this website:
www.poochiemoo.com
and they work on all browsers except Firefox, when going to any of the galleries and attempting to look at the images.
One strange thing I learned, was that when viewing this offline it worked fine. But when moving them over to the host servers, they all stopped working. After some investigating, I learned that it had to do with the host Linux servers and how I name things using upper and lower case. Most of the problems were solved, but this lightbox one seems to be getting the best of me.
Your images are 404ing. It looks like the image hrefs are all using backslashes. Chrome and IE are automatically fixing the error, but Firefox isn't.
Your links are in the format:
Images\Cupcakes\artistpalette.JPG
Change them to the format:
Images/Cupcakes/artistpalette.JPG
At the moment the backslashes are being encoded by Firefox, so links like this are generating a 404:
http://www.poochiemoo.com/Images%5CCupcakes%5Cartistpalette.JPG
I am trying to use a font awesome icon in a widget that is installed on a customers website. The font awesome icons displays correctly in Safari and Chrome but doesnt in Firefox. However, it still displays correctly in Firefox when previewing it on our site. Does this have something to do with how Firefox displays third party fonts across domains?
Any ideas would be greatly appreciated. Thanks.
Note: This was tested using Firefox V9 and above.
Firefox only allows cross-domain linking of fonts if the server the font is on sends the right CORS headers. And it does this because the spec very clearly says to do it, at http://dev.w3.org/csswg/css3-fonts/#default-same-origin-restriction
I notice a strange behaviour, probably related to the firefox security policies.
I had the same problems with a project configuration like so:
/site/html <--- where all the .html files go
/site/resources/... <--- where all the css, font, img, js stuff goes
now, I included the font-awesome.min.css in an html file located under the /site/html directory and I experimented your problem.
But when you download the Font Awesome package it is shipped with html demo files that actually works in firefox. What's the trick?!
Their project structure has the "resources" folder (they call it "assets") nested inside the "html" folder. This seems to calm down the firefox security policy.
Finally, my answer is: get a configuration like the following
/site/html <--- where all the .html files go
/site/html/resources/... <--- where all the css, font, img, js stuff goes
it worked for me.
If you are hosting your font on S3, you have to enable CORS on the bucket. See my answer to this other question for details
MaxCDN identified and fix this issue. They set the right CORS headers and embedding this line to your website should work:
<link href="//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" rel="stylesheet">
Firefox blocks Cross-Origin Request.
Firefox disallows reading the remote resource due to Same Origin Policy for below CDN:
https://maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css
I dug little to fix CORS issue instead I replaced above CDN with below one and icons rendering fine:
<link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.1.0/css/font-awesome.min.css" media="all" rel="stylesheet" type="text/css">
Use direct link for including css files , also make sure you don't get a cross-domain error in the debugging console .
For example when you access your website from :
http://www.domain.tld make sure you link css file from the same path including www
like so : http://www.domain.tld/css/style.css
and when you access from http:// > link css files also from that very same path without www.
http://domain.tld/css/style.css
i got that issue some time ago and it was fixed by modifying css paths to request css files from the "same" web address / path .
example:
you can view font awesome icons in this path
http://webake.ro/
But not in this one :
http://www.webake.ro/
because the font was linked from within http://domain.tld path without adding www. in the
link href=
Font from origin 'http://webake.ro' 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.webake.ro' is therefore not allowed access.
Turn your fonts into base64 and include through CSS. This way you push the fonts through the browser code and the font files are not downloaded in the usual fashion needing cross domain permissions. This is also a DISA STIG issue to disable downloadable fonts but probably not your issue here. The solution can be seen at this post and also copied here:
You just need to Base64 the font and include it in a CSS file. Make sure to remove your call to the downloadable WOFF file once you include the call to the new FontAwesomeB64.css
Use https://www.base64encode.org/ to encode the WOFF Font-Awesome font file.
Edit the the resulting file and add these lines. When you get to the src:url line, make sure to run that right into the base64 information you received (don't use the greater than and less than signs I show here.) At the end of that base64 information add the single quote, parentheses, a semi-colon, and curly brace to finish:
#font-face {
font-weight: 400;
font-style: normal;
font-family: 'FontAwesome';
src:url(data:application/x-font-woff;base64,<insert base64 code here>);}
You now have a base64 CSS file of the Font-Awesome font that bypasses all font download denial settings in browsers.
I've found that this works with all fonts, a little heavier on the download but worth the guarantee of functionality.
#font-face{font-family:'FontAwesome-webfont';
trust me, this really works.
I am designing a splash page for a public wifi access point and Firefox refuse to display my custom font, while it work in every other browser (well, not IE < 9 but that was expected).
The page need to work in the following constraint :
No access to the Internet : This page is displayed before the user accept the term and condition, so everything is blocked
The page is stored on the access point : That mean an embedded server probably written in C, and I can't really add additional header or something. Well its open source so it may be possible, but I am most certainly not an embedded developer!
The WiFi is used to advertise the small town in which it is offered, so it should be as pretty as possible.
To meet those constraint I used the #font-face with a data uri, like so :
#font-face {
font-family: Lato-Light;
src: url(data:application/font-woff;base64,<large base64 string>)
format('woff');
}
h1{
font-family: Lato-Light, Helvetica, sans-serif;
}
It work like a charm... Except in Firefox. Now I understand that it won't work in older IE, but I am ready to work with that. But it seem strange to me that a so-called modern browser would not offer that feature. Why isn't this working?
EDIT : Of course, I have a lot of idea for fallback, but my question here is more : Why does firefox have this behavior that is not the same as the other browsers? Is it a security setting? A bug in the data-uri implementation? A size limit for the data-uri?
In the end, the problem was that I used a woff font generator that produced an incorrect font. Safari and IE were able to read it, but Firefox and the latest version of Chrome rejected it since it contained some errors. By using a more recent woff font generator, I was able to make it work across all browser.
The correct woff font generator
http://people.mozilla.org/~jkew/woff/
For more detail, check that bugs report :
https://bugzilla.mozilla.org/show_bug.cgi?id=735556
I'd like to thank Jonathan Kew of Mozilla for providing the answer.
To cut down on HTTP requests, I subset and Base64 embedded a couple webfonts into my CSS (Font Squirrel #font-face generator, advanced settings, and for icon fonts I used icomoon.io).
Thinking I was really clever I served them from a static subdomain...No go in Firefox.
Turns out it was a restrictive cross-domain resource setting that is apparently unique to Firefox. When I uploaded the HTML5 Boilerplate 'standard' .htaccess file, it specifically permits it and it took care of the problem.
Hope it helps future readers, it stumped me for a while...sorry if my terms lack precision, I'm still pretty new at this (it is well explained in the H5BP .htaccess comments and docs).
Does anybody know why #fontface will work sometimes in Firefox but not others?
On this page... http://www.independentink.ca/gameday/indexb.htm you can see 'Design Packages' written in an embedded font. Then, I try to implement some League Gothic on the same page, as seen here... http://ggszabo.com/new/indexb.html and it won't work.
I'm viewing both in FF and one works while the other doesn't. My code is exactly the same on both.
I've searched for answers but none address this problem specifically.
My css is as follows.
#font-face {
font-family: 'League Gothic';
src: url('../fonts/League_Gothic.eot');
src: local('☺'),
url("../fonts/League_Gothic.woff") format("woff"),
url("../fonts/League_Gothic.svg") format("svg");
}
Please help!
I found an answer for local development at least...
"Firefox comes with a very strict "file uri origin" (file:///) policy by default: to have it to behave just as other browsers, go to about:config, filter by fileuri and toggle the following preference:
security.fileuri.strict_origin_policy
Set it to false and you should be able to load local font resources across different path levels."
I have yet to see if it works when published. I have reason to believe that it will.
Does anyone know are there any issues with using more than 1 or 2 #font-face declarations with IE? I'm only getting one typeface to display, the other won't at all.
Cheers
Shouldn't be. I have three of them working here: #font-face :: IM FELL English.
Have you generated the right fonts to work with Internet Explorer (eot)? This tutorial: Generating custom fonts with #font-face describes generating the correct syntax to support all browsers. No reason why multiple wouldn't work. If you're still having some issues perhaps you can post your code or example link?