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.
Related
I'm using Laravel 8 on Heroku and keep getting 404 errors for some fonts. This just started happening earlier today but I haven't changed any of my code in several days.
This is a sample of what I'm seeing from laravel's error handler:
404 - https://www.example.com/%7B%7BEXTENSION_BASE_URL%7D%7D/b06871f281fee6b241d60582ae9369b9.ttf
404 - https://www.example.com/%7B%7BEXTENSION_BASE_URL%7D%7D/fee66e712a8a08eef5805a46892932ad.woff
404 - https://www.example.com/%7B%7BEXTENSION_BASE_URL%7D%7D/af7ae505a9eed503f8b8e6982036873e.woff2
I searched my entire directory for EXTENSION_BASE_URL and it doesn't exist anywhere in my code.
The user id's associated with these errors are not unique and it seems to be happening to multiple people. It's the same three font files as above each time.
My best guess is there's some kind of plugin people have installed that's trying to use a custom font that doesn't exist. I can't find any reference to EXTENSION_BASE_URL when I do searches online, so I can't figure out where it's actually coming from.
The only custom fonts I use are an import for Raleway from the Google Fonts API. I have jQuery 2.2.4, Bootstrap 3.3.7 and FontAwesome 5.4.1 which might also be including fonts with their CSS. Aside from the Raleway include, the versions for the other CSS files haven't changed in a while.
Since it doesn't seem to be affecting everyone and I can't track down what these font files are, my plan is to simply exclude these font files from showing up in my logs. I'd love to know what caused this though so I can take any other action if necessary
We had this same problem with some of our users and we tracked it down to a browser extension called ProWriting Aid Grammar Checker which is for the website https://prowritingaid.com/.
In our case, not only was it creating the errors you mention with fonts, it also caused some JavaScript to execute improperly.
This extension is available on Chrome, Safari, Firefox, and Edge. We had users across all these browsers have the same problem. It is clear that the problem code is shared across all these browser extensions' code base.
Having users uninstall that extension solved our issues.
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.
RESOLVED
Unbeknownst to me, Cloudflare defaults to caching all css/js files for 4 hours.
Scenario:
I add this to our front page:
<span class="test">hullo!</span>
and this to our css file:
.test { font-size:2.0em; }
I do a web deploy, OR full publish to Azure and the span appears on the front page, but not the styling. The css file for some reason does not get updated. FF, IE, Chrome and Safari all confirm it. However, after a seemingly arbitrary time, the css file get updated.
Even when I remote into the Azure VM and restart the app, the styling is unchanged. The app is running on one instance, one role. No Azure Caching is setup. Adding a querystring param to the css file link does not help. Seems like a caching issue but no clue how to resolve.
Any ideas?
"We are using Cloudflare which has a default set up to cache all CSS and JS files. It purges the cache every 4 hours which resulted in the arbitrary updates. So, even though I was adding a new query string to the end of the css file, Cloudflare still cached the old one"
Just a quick note that you should go to CloudFlare Development Mode when making changes to the static content files on your site. You can get to Development Mode to bypass the cache by going to: settings->Development Mode. You also have the option of purging your cache as an additional option, which we would only recommend if you really want to purge everything.
Looks like it's cached by your browser. Can you please try navigate to your site and press Ctrl+F5.
Maybe you can use Fiddler to see if the CSS had been cached, or not updated, or some error when download.
This issue is resolved.
We are using Cloudflare which has a default set up to cache all CSS and JS files. It purges the cache every 4 hours which resulted in the arbitrary updates. So, even though I was adding a new query string to the end of the css file, Cloudflare still cached the old one.
I have dealt with this and I will tell you that from my experience in Chrome you can set a setting that disables the cache in the developer tools, however, I've noticed that unless you have the dev tools window open when you hit Ctrl+F5 it doesn't reload the cache. In IE there is a global setting in the dev tools that will make it redownload everything every time. In Firefox there is also a setting in the dev tools that will require it to download and not use the cache.
One way that you can test this, and how I test this, is by running Fiddler and watching if it does a full download of all your files or if it's caching.
From what I've experienced is that this is truly a browser caching issue and not anything to do with Azure.
It looks like IE7 doesn't reload the latest version of my stylesheet each time I upload a new version on the server.
This is annoying as I am debugging my .css file to make it work on IE...
Tried to empty the browser cache but still not working.
Thanks for your help.
Ctrl-F5 - forcible way to reload in IE
Include your version number in the file name. myfile_v1234.css
When testing, every time you do an update you can just wite "stylesheet.css?r=98123"
As long as the query string is different, it'll be downloaded again.
If you need, you can use javascript to append Math.random(), to get the random number. Not required on production though, when updates would be stable.
2 Questions:
Does IE eventually load with the newer stylesheet?
How are you saving the changes to the server (SSH, Web Interface, etc.)?
I ask because I ran into an issue with a web-based file management system a while back where one browser would show the CSS just fine, the other wouldn't, and we noticed the issue of which browser played nicely depended on which browser we used to upload the CSS.
The reason turned out to be that IE gave the CSS file a different MIME type than Firefox. If you continue to notice the issue even when you've cleared the cache, check the MIME type of the file using Firefox by going to Tools > Page Info.
Also, if it is simply a caching issue, consider turning caching off in IE. I believe this should be an Advanced Option under Internet Options.
Also, you may want to try creating a special developer environment for IE (if it comes down to it.) Perhaps have another machine with IE7 and no caching and any other features turned off (A kiosk mode, perhaps), and then previewing the page on that machine.
Thanks to you all!
I did manage to solve my problem with the "stupid" Ctrl+F5, and by changing the Internet Parameters of Windows to reload content every new visit.
I have a website that I've just uploaded onto the Internet. When I browse to the site using Firefox 3.0.1 on Ubuntu I don't see the favicon; Firefox 3.0.1 on WinXP does display it.
Why isn't the favicon displaying under Ubuntu? It's a favicon.ico file in the root directory, not referenced in the meta tags; would it work better as a GIF?
Previously, there was no favicon. The browser cached the lack of favicon. Clear the Firefox cache, and all is well.
Try taking a look at this previous Question, which shows you must put two meta tags in your html in order for it to work across all browsers and operating systems.