I'm having a strange issue loading my font faces on my new website. It seems that all but one font-face is displaying correctly.
The font in question on my website is deibi. It loads just fine on all other browsers, just not IE11 or any other version of IE for that matter.
Here is the link for comparison.
http://hemgroup.com/demoserver/jardin/
I'm done a few searches and tried a few different things but all not no avail it seems.
Any tips or suggestions on where to look would be awesome. Thanks everyone.
I can't seem to be able to replicate the problem but i did see some errors in IE when loading the page.
I was receiving this error message when loading your page:
CSS3117: #font-face failed cross-origin request. Resource access is restricted.
File: deibi-webfont.eot
CSS3117: #font-face failed cross-origin request. Resource access is restricted.
File: economica-regular-otf-webfont.eot
IE has very strict rules on loading fonts and font permissions and i think that these may not be setup right. The headers may also not be being called in correctly and therefore may be causing an error on your side.
Have a quick read up on this error which i think is what the problem is: IE9 blocks download of cross-origin web font
Related
I have been fighting with this problem since some weeks, and after all the researches...., I think I need your help.
It's about my website: shoother.net
It seems to work fine with Safari, but if you use Firefox and Chrome, the icons wont show up. Just scroll down the home page until the last section "Get Connected" or in the about or contact-page.
The problem started while I was trying to solve CDN issues. I wanted to make my pictures load faster, and moved wp-content/upload-content in the main root. Everything worked perfectly first (I even minified the JavaScript files), but then the icons won't load anymore.
I wrote to the theme-support about it, and they told me that I need to enable CORS with some codes (putting it in .htaccess).
I tried a lot to solve this problem. Chrome always responds with
"Font from origin 'http://content.shoother.net' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'xxxxxxx' is therefore not allowed access."
.... I really hope you guys can help me.
Regards,
Natts
Console messages:
The page at [...] ran insecure content from http://fonts.googleapis.com/css?family=Quicksand.
and
The page at [...] displayed insecure content from http://themes.googleusercontent.com/static/fonts/quicksand/v2/sKd0EMYPAh5PYCRKSryvWz8E0i7KZn-EPnyo3HZu7kw.woff.
and
Resource interpreted as Font but transferred with MIME type font/woff: "http://themes.googleusercontent.com/static/fonts/quicksand/v2/sKd0EMYPAh5PYCRKSryvWz8E0i7KZn-EPnyo3HZu7kw.woff".
I know what caused it--vaguely. I just started implementing Stylus, Nib CSS modules.
In my Google research I found: http://mccormicky.com/1595/importing-google-web-fonts-lightspeed-web-store-ssl/
which makes it clear that the font requests should be switched to https for the whole thing to be considered secure, so then I looked into my /public/styles/style.styl file and found the offending line. One extra s should be sufficient to clear the warning. Indeed it's fine now.
It's really as simple as making the font request (found in the CSS styles file) over https instead of http.
I hadn't intended to be answering my own question (really thought the fix would be something complicated with the headers), but by the time I'd half finished it and done my due diligent research it was answerable. So, whatever.
I'm developing a Chrome extension that has an options page. And I am willing to style this page same as Chrome options page is styled. I found that there is a file
chrome://resources/css/widgets.css
that holds this style (it is listed in "Developer Tools > Sources"). However, if try to load it in my page either directly from HTML
<link rel="stylesheet" href="chrome://resources/css/widgets.css" type="text/css">
or from CSS
#import url("chrome://resources/css/widgets.css");
then get this error printed in the console:
"Not allowed to load local resource: chrome://resources/css/widgets.css
It looks like I'm missing some permissions in my manifest.json, but did not find anything suitable on the developer's pages (notice it lists "chrome://favicon/", but that's it).
Anyone knows a solution?
P.S. Yes, I have copied this file into my extension's folder, and I got what I want, but the smart and proper way using this file (IMHO) is loading it directly from Chrome resources.
Short answer: No, you can't access chrome://resources... from an extension.
First, it's blocked on purpose, thus why you see "Not allowed to load local resource." Second, you really shouldn't rely on Chrome's resources, which can change in any version.
I thought I have somehow found a solution to the very vexing problem with Firefox and CDN-hosted fonts access, but here comes IE9.
I recently found a very frustrating issue with IE9 caching problem, and chanced upon this blog post (IE9 Redirect Caching Nightmare) which enlightened me more about the actual issue.
I have to admit that I'm not sure whether the above mentioned is actually the issue, but it seems close enough.
Problem:
I have a website set up with 2 domains(base domain and subdomain) pointing to the same server, serving the exact same website which is using a same set of resources from a CDN hosted on Amazon S3, served by Cloudfront.
https://example.com
https://www.example.com
I get these kind of error messages in my IE9 developer tools console when loading fonts from my CSS file using #font-face:
CSS3117: #font-face failed cross-origin request. Resource access is restricted.
This happens when I loaded either of the URL first, then visiting the other second. IE9 is not running in Compatibility Mode. It running is in Document Mode: IE9 Standards.
From my limited understanding of the CORS and the need to set Access-Control-Allow-Origin HTTP header, I have dutifully set it up in S3 CORS policy, and it works perfectly fine with Firefox.
Requests from both domains, will get their respective header when requesting the CDN resource.
It seems that IE9 tried to do some optimization with caching, and cached the redirect too.
This causes a problem as the Access-Control-Allow-Origin header is cached as well. Without sending a request to the CDN server, the Access-Control-Allow-Origin header cannot change for different domains.
So I'm left with a situation where the request is from https://www.example.com and yet the Access-Control-Allow-Origin is https://example.com. This leads to the restricted resource problem with the error message above.
Further look: I did a check with Firefox 19, the above situation actually occurs, but it does not encounter the same strict restriction as IE9. Subdomain (https://www.example.com) requesting information will accept the access-control-allow-origin of the main domain(https://example.com). Chrome (Webkit) doesn't seem to care. I'm at a loss about which browser's behaviour implementation is correct.
With my current settings in the CDN, it seems like Chrome and Firefox, automatically reroutes allwww subdomain requests to the main domain. Only upon multiple attempts of inputing the www subdomain in the address bar, then will Chrome and Firefox obey. IE9 on the other hand, just goes to whichever address is typed in the address bar. IE9 seems to be the odd one out here, but I'm not sure which browser's behaviour is actually correct.
From a usability standpoint, Chrome and Firefox seems to be the "correct" behaviour.
Known Possible Solutions:
Set Access-Control-Allow-Origin header to allow all, i.e. *
Turn off caching in the browser
Redirect one domain to the other
Use query string to differentiate different domain calls for resource
Embed the font into the CSS as data-uri
For solution 1, let's just say I'm paranoid that I just want to set specific domains to allow.
For solution 2, is not optimal if I were to set it for all browsers, also my site has to run on mobile devices with usually less-than-desirable download speeds.
For solution 3, possible, but I'm still curious for solution to deal directly with the IE9 caching issue.
For solution 4, it is very hard to implement especially when the resource is called from #font-face. Does it mean that I'll have to dynamically re-generate the CSS for different domain calls for the different line just to load a font to bypass the issue? Seems to defeat the purpose of CSS itself, and caching resources for that matter.
edit: Stylesheet works, font-loading doesn't.
For Solution 5, it is tedious for maintenance and updating, especially when there are changes to the font files periodically.
Question: Are there any known ways to deal specifically with IE9's redirect caching behaviour in this particular case?
Answers and comments are very much appreciated. Thanks in advance!
Edit: More browser test information.
Solution 1:
Check this question.
Solution 4: rename your CSS file to style.php and use whatever code you need to call the appropriate resource.
Set the content type at the top of the page.
<?php
header("Content-type: text/css; charset: UTF-8");
?>
More info about style.php from Chris Coyier.
We discovered the same weird behavior also in IE10 and IE11.
Resetting the browser cache makes the fonts to be loaded without any problem. Also enabling and disabling compatibility mode.
But when switching to another subdomain, IE does not render the font because request header does not match the response header which is still the URL of the last request. And IE always shows the full URL for even if the definition on the bucket is *.ourdomain.com
So the general issue with allowing cross origin requests to assets like webfonts was solved by adding CORS permissions to the S3 Bucket - that made the webfonts work perfectly in Firefox.
But we still have no idea how to avoid * and tell IE not to cache the response headers.
When I render webpages with PhantomJS using Node.js on an EC2 server, I have trouble loading fonts. I have looked this problem up on Google and while people are having issues with this, none of the solutions really helped me. What I am looking for is a method for debugging PhantomJS and #font-face. I want to see what font files it is trying to load and where the problem might be occurring so I can fix it myself. Obviously this is very vague so here are some images detailing my problem:
Rendered on localhost (fonts are installed on the machine): http://imgur.com/o305T
Rendered on EC2 (fonts should be loaded from an external css file): http://imgur.com/6CQW7
I think the answer is pretty easy: You're rendering the image before the FOUT is resolved.
Check this: How to know when font-face has been applied