Basically what happens is, that Firefox doesn't load my typefaces when my index.html is not in the root folder.
If I put the same index.html in a sub folder (and relink the href's), everything loads fine but the typefaces. If I upload them to my server, everything works fine. So the problem is just locally.
It's really weird.
This is what I use for my font-face rule:
#font-face {
font-family: pt_sans_condensed;
src: url(../fonts/PTN57F.ttf);
}
(I only have this in firefox)
Mr Lister solved my issue.
Type in firefox's search bar: about:config
And look for: security.fileuri.strict_origin_policy
Set it to false, and Firefox will load fonts across different paths!
Related
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')
}
background-image:url(chrome-extension://__MSG_##extension_id__/image.png);
For an extension that works for Firefox and Chrome, I just need to refer to a single image file in a CSS file.
chrome-extension:// works only for Chrome
moz-extension:// works only for Firefox
So I am stuck to create 2 separate CSS files just for single line of code.
Is there any short-cut for both of protocols?
Relative paths does not work for Chrome. Rather than searching in the root directory of the extension, Chrome searches the image file in web site root directory.
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.
I have a quite specific IE9 problem that relates to this for example (but here it only refers to IE8 and less) IE8 web font iframe bug workarounds
I have pages that have iFrames inside iframes like so
Top page
-- iframe1.html
-- -- iframe2.html
-- -- -- iframe3.html
The iframe 2 is loaded by iframe1 dynamically. I also have a fonts.css style sheet that has fonts encoded in this way:
src:url(data:font/opentype;base64, /*FONT HERE */
that is located next to iframe1's folder in
/%folder_with_top_page%/%folder with iframe1.html%/style/fonts.css
iframe2.html loads the fonts.css file from that folder:
<link rel="stylesheet" type="text/css" href="../style/fonts.css" />
And this works with other browsers just fine, except in IE9 the result is following:
page loads
page flashes with correct fonts
page reverts to New Times Roman/default serif font
Looking at the Network tab in dev tools in IE9 it shows that the browser is trying to load the fonts file from the root folder:
404 %folder_with_top_page%/style/fonts.css
Everything works just fine if I also place the fonts.css file there, but that seems unnecessary. There is also a file called fonts.css in %folder_with_iframe3.html%/style/fonts.css, which loads fine and seems to relate to the problem described in the first link, but I assumed the problem was fixed in >IE9? I know that the page structure isn't optimal in any case, but it's not up to me to change it.
My questions are as follows:
1) Is this the same problem as described in the link I posted but in IE9 instead?
2) Which would be the workaround that makes the most sense: just inserting the fonts file to the "correct" (= wrong, root-ish) folder, putting the fonts.css file to the same level as the file thats loading it (aka copying the file to %folder_with_iframe2.html%/style/fonts.css) or something else (such as appending the CSS again to the page with jQuery after the site has loaded).
The behaviour only happens with iframes but not when loading the pages individually.
I just stumbled on this post while diagnosing a similar issue with an embedded iframe trying to load a stylesheet with a relative link, and the request going to the outer page. To solve it, I appended the link tag to the DOM, then set the href attribute with JS.
var cssLink = "<link rel='stylesheet' type='text/css' id='addcss'/>";
$('head').append(cssLink);
$('#addcss').attr('href', src);
I was able to reproduce the issue consistently when including the href in the initial tag, and was unable to reproduce it after implementing this fix.