X
Thinta lapha ukuze uye kuveshini yamakhalekhukhwini kusayithi.

Isithangami Sabeseki

Fontawesome works in chrome but not in firefox

Kuphostiwe

I'm working on a simple webpage and I noticed that fontawesome fonts don't work in Firefox, but it does work in Chrome. Why?

I'm working on a simple webpage and I noticed that fontawesome fonts don't work in Firefox, but it does work in Chrome. Why? <div id="footer-icons"> <a href="#" target="_blank"><i class="fab fa-facebook-f fa-2x" aria-hidden="true"></i></a> <a href="#" target="_blank"><i class="fab fa-twitter fa-2x" aria-hidden="true"></i></a> <a href="#" target="_blank"><i class="fab fa-github fa-2x" aria-hidden="true"></i></a> <a href="#" target="_blank"><i class="fab fa-google-plus-g fa-2x" aria-hidden="true"></i></a> </div>
Ama-screenshot ananyekiwe

Isisombululo esikhethiwe

Hi wfarrar, I assume the deployed/live site still looks normal?

Firefox 68 contains a security patch which restricts the kinds of files that pages can load 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.

Font files don't seem that valuable, so hopefully there will be an exception for those in the future.

For now, though, if you need to see fonts retrieved on file:// URLs during local development, you can roll back the patch as follows:

(1) 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.

(2) In the search box above the list, type or paste uniq and pause while the list is filtered

(3) Double-click the privacy.file_unique_origin preference to switch the value from true to 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.

Hopefully all of that will be educational for your students.

Funda le mpendulo ngokuhambisana nalesi sihloko 1
Isicaphuno

Eminye Imininingwane Yohlelo

Fakela amapulagi

none

Isisebenziso

  • I-ejenti Engumsebenzisi: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Eminye Imininingwane

cor-el
  • Top 10 Contributor
  • Moderator
17273 izisombululo 156142 izimpendulo
Kuphostiwe

Impendulo Ewusizo

You can check the Web Console and Network Monitor. *https://developer.mozilla.org/en-US/Tools/Web_Console *https://developer.mozilla.org/en-US/Tools/Network_Monitor
Ingabe lokhu kube usizo kuwena? 1
Isicaphuno

Umnikazi wombuzo

The first link is for the javascript console but this is not a JavaScript Problem. Not sure how the network monitor helps. The code is correct, it works in Chrome, Safari and IE. This is a Firefox problem.

For now I will inform my students Not to use Firefox, until I can figure out the problem

The first link is for the javascript console but this is not a JavaScript Problem. Not sure how the network monitor helps. The code is correct, it works in Chrome, Safari and IE. This is a Firefox problem. For now I will inform my students Not to use Firefox, until I can figure out the problem
Ingabe lokhu kube usizo kuwena?
Isicaphuno
jscher2000
  • Top 10 Contributor
8509 izisombululo 69508 izimpendulo
Kuphostiwe

Isisombululo Esikhethiwe

Hi wfarrar, I assume the deployed/live site still looks normal?

Firefox 68 contains a security patch which restricts the kinds of files that pages can load 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.

Font files don't seem that valuable, so hopefully there will be an exception for those in the future.

For now, though, if you need to see fonts retrieved on file:// URLs during local development, you can roll back the patch as follows:

(1) 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.

(2) In the search box above the list, type or paste uniq and pause while the list is filtered

(3) Double-click the privacy.file_unique_origin preference to switch the value from true to 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.

Hopefully all of that will be educational for your students.

Hi wfarrar, I assume the deployed/live site still looks normal? Firefox 68 contains a security patch which restricts the kinds of files that pages can load 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. ''Font files don't seem that valuable, so hopefully there will be an exception for those in the future.'' For now, though, if you need to see fonts retrieved on file:// URLs during local development, you can roll back the patch as follows: (1) 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. (2) In the search box above the list, type or paste '''uniq''' and pause while the list is filtered (3) Double-click the '''privacy.file_unique_origin''' preference to switch the value from true to 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. Hopefully all of that will be educational for your students.
Ingabe lokhu kube usizo kuwena? 1
Isicaphuno
jscher2000
  • Top 10 Contributor
8509 izisombululo 69508 izimpendulo
Kuphostiwe

wfarrar said

The first link is for the javascript console but this is not a JavaScript Problem.

Have you not used Firefox's Web Console? It would have flagged up a CORS issue retrieving the font files, because the patch redefines "same origin" in the context of file:// URLs. Admittedly, that would not have led you to the workaround, but telling us that's what you saw could have been helpful.

''wfarrar [[#answer-1237344|said]]'' <blockquote> The first link is for the javascript console but this is not a JavaScript Problem. </blockquote> Have you not used Firefox's Web Console? It would have flagged up a CORS issue retrieving the font files, because the patch redefines "same origin" in the context of file:// URLs. Admittedly, that would not have led you to the workaround, but telling us that's what you saw could have been helpful.
Ingabe lokhu kube usizo kuwena?
Isicaphuno
Buza umbuzo

Kufanele ulogele ukungena ku-akhawunti yakho ukuze uphendule amaphosti. Uyacelwauqale umbuzo omusha, uma ungekabi nayo i-akhawunti namanje.