The following site ie(http://test.cancer.org.in/) does not looks properly in firefox but it looks proper in IE(internet explorer) and the error it displays is :
The Components object is deprecated. It will soon be removed.
resource://ftdownloader3-at-ftdownloader-dot-com/api-utils/lib/loader.js -> resource://ftdownloader3-at-ftdownloader-dot-com/api-utils/lib/sandbox.js -> resource://ftdownloader3-at-ftdownloader-dot-com/api-utils/lib/content/content-proxy.js
Line 13
Regarding the plugin error, you should contact the people that create the plugin, they're the only ones that can help you there. But that issue is unrelated to the display issues you're having.
Concerning your site, the fact that it looks horrible in both IE10 and Firefox, but OK in IE8 is because the styles don't get applied. What I know is that if your server is misconfigured and transmits css files with a content-type other than text/css, this will cause issues in Firefox when using xhtml doctype - it won't use the css files that way. You should reconfigure your webserver to send text/css for css files and application/javascript for js files.
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 customizing iNotes (Notes web mail client), adding some features using javascript that require ajax calls to external sources. In doing so I have found Internet Explorer won't perform CORS (cross-origin) requests. Errors are either access denied or some other security errors depending on how it's called. Chrome and FF and Safari all work.
I have found what I believe to be the culprit, iNotes adds a meta-tag to emulate IE9.
<META http-equiv="X-UA-Compatible" content="IE=EmulateIE9" />
For CORS requests, IE9 does not support XMLHttpRequest, rather you must use XDomainRequest, which was only supported in IE8 and IE9. Since it's emulating IE9, the XMLHttpRequest (or jQuery .ajax calls for that matter) don't work.
I have not been able to find any way to remove that meta tag, I did a search on the mail file and there are no matches for IE=EmulateIE9 that I could find. And I'm sure if I did remove it, I would break something in iNotes.
I didn't want to load jQuery, but may do so for this script and include the moonscript plugin which uses XDR for ie8 and ie9 browsers. If iNotes is ever updated, it will still work.
Anyone else run into this problem and find a better solution?
Lothar Mueller pointed me in the right direction.
Domino 9.0.1 Fix Pack 5 adds a Forms9s.nsf which allows you to get rid of "Quirks Mode" for IE backwards compatibility. After installing the FP, the new forms9s.nsf file is installed, then you update the notes.ini with
iNotes_WA_DefaultFormsFile=iNotes/Forms9s.nsf
iNotes_WA_FormsFiles=iNotes/Forms9s.nsf
and it eliminates the emulation tag for IE. I still have to test my iNotes customization apps, but this gives an option for running some IE features that didn't work before such as Ajax requests from iNotesExt_9.nsf, etc.
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.
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.
In Safari 5.1.2 on OSX
Tech.li is completely broken.
Some people mentioned an extra div tag being the cause, but that still didn't fix the issue.
Any help would be greatly appreciated!
Pretty basic: fix your xhtml errors [Invalid] Markup Validation of tech.li - W3C Markup Validator (scroll down in the validation report to see line numbers and source code). And use Firebug with Firefox, or in Chrome or Safari or IE8, use the developer tools to find and fix the javascript errors.