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.
Related
The Html
<link rel=stylesheet href=../static/css/foundation-icons/foundation-icons.css>
<a class="button radius search-header"><i class="fi-magnifying-glass"></i> Search</a>
I have navigated to foundation-icons.css after hitting Ctrl+U within Firefox so I am definitely linking to the file correctly.
I have copied the foundation-icons folder exactly and not removed anything. It looks like this:
./static/css/foundation-icons/
- foundation-icons.css
- foundation-icons.eot
- foundation-icons.svg
- foundation-icons.ttf
- foundation-icons.woff
- svgs/*
- preview.html
Edit: I have changed the title and added the Firefox tag because everything seems to be working fine in Chromium. I am a little stumped because that means it's a Firefox issue and probably not possible for me to fix.
The preview.html file that comes with foundation-icons works correctly in my Firefox as well.
If you're using the SCSS files, you should point the $fi-path variable to the correct location of your foundation-icon-fonts folder.
For me I had to add the following before importing foundation-icon-fonts:
$fi-path: 'foundation-icon-fonts';
First correct this:
<link rel="stylesheet" href="../static/css/foundation-icons/foundation-icons.css">
In examples of Foundation, Firefox use .woff files. Check if you have access to them.
It's a relative path. Are you sure 'static' folder is reachable with your browser ?
Trying to use Bootstrap 3.0 (pulled via Bower) Glyphicons icon font in an app. Works perfectly in all browsers locally.
In a staging environment on heroku, icon font isn't working on Firefox. Font is hosted in an S3 bucket WITH cross-domain settings setup -- this has been verified by testing the font with a curl command as described here. I get a 200 response, no issues. So, the fonts in the right place (not a path issue) and accessible (not a cross-domain issue -- probably.)
In fact, when I look in the Network panel in firefox, I see a 200 response on the fonts... But the file size is listed as 0kb.
I have tried multiple content types (font/x-woff, application/x-woff), I have tried using font-squirrel's base 64 encoding (didn't work).
I've seen that Bootstrap's customized downloader has broken fonts but this is straight from the repo via Bower.
I have no idea what else to try. Halp?
Don't know if you ever got this solved or not, but I hit the same issue today and the cause of it is because Firefox is a bit strict about hosting your font on a separate domain. If you check out the Firefox web console, it should show an error like this:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at
http:// path/to/fonts/glyphicons-halflings-regular.ttf. This
can be fixed by moving the resource to the same domain or enabling
CORS.
Apparently, there's a way to configure your S3 bucket to stop this from happening ( Boootstrap glyphicons Firefox issues ), but I haven't tried it yet.
Just looping back on this-- brushed the icon font aside in favor of an SVG solution, and in the interim we changed CDN providers, and redid all our CDN settings, while the S3 bucket settings remained the same. Checked the icon fonts in Firefox and voila, no more issues.
So I think our CDN's settings were somehow not passing through the needed permissive S3 settings, or so my coworker suggested.
So I have this #fontFace rule
#font-face {
font-family: 'myriadPro-Black';
src: url("fonts/myriadPro-BlackCond.otf") format("opentype");
}
It works in Chrome and Safari, but not Firefox. I understand that Firefox has different rules for fontface than other browsers, but I am having a hard time understanding. Getting used to cross browser optimization.
Any ideas on what I'm doing wrong?
Multiple extention's for wider support:
How i generate my fontface rule's is by using a online generator.
It save's a lot of time as it write's everything in the good order.
Plus it make's sure you support a wide variety of different extentions.
An example of such a generator can be found here: http://www.fontsquirrel.com/tools/webfont-generator
Security problem with firefox:
FireFox has secured the #font-face. Firefox for example might throw a 301 error, saying you don't have permission of access to the font file and therefor not load it, while other browsers don't.
You could give the right permissions using .htaccess or whatever config file for the webserver you working on but since i use a variety of webservers this is annoying. What works best for me is placing the font file's in the same directory as the .css file.
So i have one external fonts.css file containing all the css font line's within the font directory. Then i can include this .css file on the page i would like to use this font. Make sure you don't make additional directory's so you can call the font without anny directory. In your example, placing the font file in your css directory and change the code to:
#font-face {
font-family: 'myriadPro-Black';
src: url("myriadPro-BlackCond.otf") format("opentype"); }
more info: https://developer.mozilla.org/en-US/docs/Web/CSS/#font-face
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).
This may be more of a tech support issue, but I'm wondering if any other developers have come across this:
I'm using Abcpdf in my ASP.NET code to generate a PDF from HTML. It works fine, but one user is generating PDFs that don't have the CSS applied (IE8, Adobe Acrobat latest version - same as everyone else). Since this is the only user complaining, I'm sure it's a local setting, but I can't figure out what would prevent the css from loading - a browser setting? An Acrobat setting?
Does anyone have any suggestions?
Perhaps an issue with different versions of Acrobat reader? I'd look into this.
This doesn't make a lot of sense because AbcPdf uses service side logic to create the PDF based on what methods you are using to create the document (ex. AddImageUrl vs drawing out the document manually, etc.).
For what it's worth the staff at WebSuperGoo (the vendor of AbcPdf) is great with replying to support questions such as this. I've run across a few edge cases with their product that they've always followed up with workarounds or alternatives to address in a timely manner.
make sure you have media="print" for the CSS style sheet! Just spent ages looking at this pulling my hair out and was about to email WebSuperGoo then that thought came to me.
just about to back out all the changes I've made to my code and test again but it looks like with EngineType.Gecko it needs to be media="print" where as with EngineType.MSHtml it can be media="screen".....
very odd but hope that helps someone!
Make sure that the CSS is an absolute URL rather than relative, or add a base tag to the header of the HTML
For example, rather than
<style type="text/css" href="/styles/somecss.css" rel="stylesheet" />
use
<style type="text/css" href="http://myserver.com/styles/somecss.css" rel="stylesheet" />
Also if you site is SSL or authenticated then you will have to either make the area with the stylesheet un-authenticated, or, set the password and username attributes of the PDF object so that ABCPdf can authenticate
You can try the following in version 9
doc.HtmlOptions.PageLoadMethod =
PageLoadMethodType.WebBrowserNavigate;
I am using Version 10 of ABCpdf and I found that the style sheet path should be absolute instead of relative.
I changed the stylesheet path from "C:\MyProject\Resources\Styles.css" to "http:\www.MyDomain.com\Resources\Styles.css" and it worked.
Although, version 6 seems to be working with relative paths. I didnot check it with other versions
As per WebSuperGoo support:
(Query # : 6.17)
HTML does not exist within a file and so it does not have a location.
External stylesheets and images are often referenced via relative URLs. Because the HTML has no location it is impossible to resolve
these relative references.
So you need to provide your stylesheet and image links as absolute references. Or you may be able to use the HTML BASE element to specify
an appropriate base location. Or you can save your HTML to file in an
appropriate location and then use AddImageUrl.
Have you tried;
theDoc.HtmlOptions.DoMarkup = true;
This forces the engine to process the HTML before rendering.