Confirmed. It happens to me too. After clearing the browser cache and reloading the page, everything is back to normal.

Does anyone have this issue?

Using Joomla5 since 2 month never happened.

System information

PHP Built On Linux lamp302.cloudaccess.net 3.10.0-962.3.2.lve1.5.81.el6h.x86_64 #1 SMP Wed May 31 12:07:35 UTC 2023 x86_64
Database Type mysql
Database Version 8.0.34-cll-lve
Database Collation utf8mb4_general_ci
Database Connection Collation utf8mb4_0900_ai_ci
Database Connection Encryption None
Database Server Supports Connection Encryption Yes
PHP Version 8.1.26
Web Server Apache
WebServer to PHP Interface cgi-fcgi
Joomla! Version Joomla! 5.0.1 Stable [ Kuboresha ] 28-November-2023 16:00 GMT
Joomla Backward Compatibility Plugin Enabled (classes_aliases:"1", es5_assets:"1")
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0

It happens to me quite often as well. Thought it was just me but obviously not

Does the network tab of the browser's developer tools show something when this happens, or does the browser's error console?

@brianteeman Is it also with the Chrome browser in your case? Or also with other browsers?

@brianteeman Is it also with the Chrome browser in your case? Or also with other browsers?

My colleagues are using firefox and do not face this issue till j5 update. Thought might because chrome and nvidia graphic card.

@brianteeman Is it also with the Chrome browser in your case? Or also with other browsers?

I only use Chrome on Windows

Does it also happen with Joomla 4.4.x? Or only with 5?

Does it also happen with Joomla 4.4.x? Or only with 5?

For me just in j5

It seems just in J5

UPDATE: it also happens on J4

Do you have any conflicting Fontawesome installed before updating?

I cannot replicate - win11 with different browsers but always correct icons. A conflict with former versions could explain the effect

Completely clean install just now on localhost of current 5.1git.

No console errors and as soon as you hit refresh it works

Maybe the issue is somehow related to the font-display CSS property? Maybe it has something to do with optimizations with Chrome version 83 for handling "font-display: optional" which are mentioned on this page https://web.dev/articles/preload-optional-fonts?hl=en and more detailed handled here: https://bugs.chromium.org/p/chromium/issues/detail?id=1040632 ?

Unfortunately I can't reproduce it here.

I can't reproduce it on demand either. Although lats night I did see it twice on a site that was not one of my own. The link you shared about font-display does sound similar

I cannot reproduce it,
However I suspect it may also be related to file loading or server response. Because of:

... and as soon as you hit refresh it works

That sounds like the initial load went wrong, and cached version works.

Try disable cache:

• Open Dev Tools Network tab
• Check "Disable cache" checkbox
• Reload the page. Now every reload will be without cache while Dev Tools is opened.

Do you able to reproduce it every time now?
Addittinaly try "Network throttling".

If you able to reproduce then also please look for a response headers for fa-solid-900.woff2 does it font/woff2 or something else?

I just observed this on a developers website

When I checked with chrome inspector it did show the woff2 files as loaded
It did NOT show joomla-fontawesome.min.css as loaded
It did not show any errors

when the icon get error, chrome didn't load any css from joomla

And this is when no icon issue

fact: open new tab with same url, the issue will gone
fact2: i even faced this issue when using a site that behind cloudflare cdn

I strongly suspect that this is caused by something related to #32141

// Defer fontawesome for increased performance. Once the page is loaded javascript changes it to a stylesheet.

I strongly suspect that this is caused by something related to #32141

// Defer fontawesome for increased performance. Once the page is loaded javascript changes it to a stylesheet.

@brianteeman Yes, I have the same thing in mind. On my private website I have disabled that lazy loading of the fonteawesome fonts in my child template.

Nope, that PR affecting only frontend, and the issue about admin side.

Update: chrome on ubuntu also got this issue.

It’s either:

• the server (mime types, etc)
• Some plugin doing something stupid
• Wrong CSP configuration

Another thing I would probably try is to use the preload header for the fonts for admin.
In j4 FA font files size ~160kb
in j5 FA font files size ~260kb

At the time we were doing those optimizations preload wasn’t supported across the board but now should be done, no questions asked

It’s either:

• the server (mime types, etc)
• Some plugin doing something stupid
• Wrong CSP configuration

At least in my case I have observed this with clean joomla installs so that would rule out the plugin or csp and if it works on reload it cant be the mime types

@brianteeman can you please try to test following code? it adds a font 'preload' header. Place it somewhere in index.php of the admin template.

$pm = $this->getPreloadManager();
$pm->preload(Uri::root(true) . '/media/vendor/fontawesome-free/webfonts/fa-brands-400.woff2', ['as' => 'font', 'type' => 'font/woff2', 'crossorigin' => 'anonymous']);
$pm->preload(Uri::root(true) . '/media/vendor/fontawesome-free/webfonts/fa-solid-900.woff2', ['as' => 'font', 'type' => 'font/woff2', 'crossorigin' => 'anonymous']);

@Fedik this Uri::root(true) . '/media/vendor/fontawesome-free/webfonts/fa-brands-400.woff2' won't actually work as expected because the URL of the font is versioned in J5 (ends with something like ?954876) which means that the preloaded font will not be the same as the one specified in the css, basically the browser will download the fonts twice (there will be a warning also in the console). The actual URL could be picked in the build time of the packages before the release (doing it at run time is not a good idea)

@brianteeman do you get this if your browser has disabled all the extensions (or in incognito mode). There a very good chance that some of your chrome extensions is misbehaving...

@dgrammatiko its random and not reproducable unfortunately but clearly effecting multiple people

@dgrammatiko it will work, because its is not versioned, I have tested on my test server, and the font loaded only once with preload tag.
But I do not have the reported issue, so can't say if it fix anything. Someone who have this issue should do testing.

@Fedik loading the font is not the problem #42611 (comment)

it is diferent, it about pre-loading not just loading

it is diferent, it about pre-loading not just loading

@Fedik this guy in this comment did NOT had the (or any) css file loaded, so the problem is probably different (ie browser extension/server problem)

s

it is diferent, it about pre-loading not just loading

That will still be nothing to do with the css which is where the problem is

did NOT had the (or any) css file loaded

the css which is where the problem is

There no problem with CSS, I suspect it is a misuse of dev tools,
it does not show anything useful when you open it after page is loaded

FWIW the installable package for 5.0.2 for both the fontawesome.[min.]css files doesn't have any entry for the path of the font. That combined with other css related breaks I think point out that switching postcss to lightningcss probably was not tested enough. Someone needs to confirm that the font url() is actually missing and then someone needs to figure out why, etc Scrap that looking at the wrong file

it does not show anything useful when you open it after page is loaded

Who said it was opened after page load

Who said it was opened after page load

Me. Look at the screenshots, also without any css whole site would be broken.

When an icon error occurs, the fontawesome.css is loaded from the template "atum," not from Joomla media. Additionally, the icon content appears abnormal.

Upon examining the original fontawesome.css from the "atum" template, it is evident that the icon content is also irregular.

This differs significantly from the fontawesome.css found in Joomla media or the FontAwesome GitHub repository.

Can someone please test, if update Fontawesome to newest version helps #42721
Thanks.

For reference:

• FortAwesome/Font-Awesome#10842
• sass/libsass#1235
• FortAwesome/Font-Awesome#17644

Please try following, edit Fontawesome css, manualy and place:

@charset "utf-8";

at top of each file .css and .min.css:

media/templates/administrator/atum/css/vendor/fontawesome-free/fontawesome.css
media/templates/administrator/atum/css/vendor/fontawesome-free/fontawesome.min.css

it looks like Browser get confused with content encoding, randomly.

@Fedik what's unfortunate here is that when we had Postcss, the @charset was always appended...

Basically if it's a lightningcss issue (ie: parcel-bundler/lightningcss#310) someone could enable debug and check if the problem occurs there as well (the non minified css file is not passed through lightningcss iirc)

The description in this comment exactly matches my own observations FortAwesome/Font-Awesome#10842 (comment)

@dgrammatiko it more about sass compiler (or probably both sass and lightning css), this potato removes @charset when detect UTF8, even with charset: true.
Only way I see is to prepend it manualy

@dgrammatiko it more about sass compiler (or probably both sass and lightning css), this potato removes @charset when detect UTF8, even with charset: true. Only way I see is to prepend it manualy

Hi,
I've compiled font awesome of atum template by using dart-sass, and the result is very different. Could you check?
The left is mine, the right is from joomla atum

Your with escaped symbols, and joomla with non-escaped.
Techicaly both should work the same, but somehow non-escaped seems not always as good as should.

Isn’t sass and dart-sass the same package?

Isn’t sass and dart-sass the same package?

If you use this command to install sass

npm install -g sass

so it's dart-sass.

https://www.npmjs.com/package/sass

Btw, we use sass-embedded wich is dart-sass, version 1.67

Btw, we use sass-embedded wich is dart-sass, version 1.67

I noticed that in the package.json file, but I'm not sure why my compiled CSS is significantly different from Joomla's.

Okay, it clearly sass LightningCSS and browser issue.
Sass (dart-sass) stopped escaping non ASCII symbols, and the Browser may interpret the file with this symbols incorrectly (randomly, due to network or enabled gzip/deflate on server), unlles the file have defined @charset 'utf-8' (which sass also deleting successfully)

Another links:

• sass/dart-sass#568 (issue from 2019)
• https://stackoverflow.com/questions/25488037/sass-compile-fontawesome-preserve-notation
• sass/dart-sass#998
• parcel-bundler/lightningcss#310

@trananhmanh89 what version of sass did you use?

@Fedik I'm using Dart Sass 1.71.1 on my windows.

Sorry, it is not Scss (it works fine, and keep the icons escaped) (I have edited my previous comment)
It is LightningCSS which is transforming escaped UTF8 to raw :)

Possible fix: #42938

Please test it

I am going to assume this is fixed with #42938. If not, this can be reopened. Thanks for the report.

I am going to assume this is fixed with #42938. If not, this can be reopened. Thanks for the report.

No, it's not resolved yet. Please do not use raw utf8 for fontawesome. This causes font issue on chrome.

No, it's not resolved yet.

@trananhmanh89 how did you tested it? (recent changes)
The fix only will be in upcoming 4.4.4 and 5.1 release.

Also, do not trust what browser dev tool shows you, it is not able to render every simbol in dev console.

@trananhmanh89 how did you tested it? (recent changes) The fix only will be in upcoming 4.4.4 and 5.1 release.

Also, do not trust what browser dev tool shows you, it is not able to render every simbol in dev console.

Hi,
This issue happens randomly, and only on chrome. How can I make sure that this won't happend again?

I thought the solution would be using escaped utf8 string instead of raw utf8 to avoid browser issue...

I just wanted to be sure whether you tested on dev branch of 5.1-dev or not.

I thought the solution would be using escaped utf8

It one of possible solutions.
Another one is to prepend encoding to the CSS file, that what was done in #42938

So if you able to test on latest 5.1 RC, that would be nice.
https://github.com/joomla/joomla-cms/releases/tag/5.1.0-rc1

Ok, I asume that adding @charset rule could fix the icon error. But why don't I see @charset rule in file fontawesome.css of atum template?

Checked on package Joomla_5.1.0-rc1-Release_Candidate-Full_Package.zip

But why don't I see @charset rule in file fontawesome.css of atum template?

Confirmed. Someone needs to check why (caching, something else?) The npm tools code seems to have the required changes...

FWIW J4 is correct:

So maybe the release leader didn't start on a lean branch and didn't run npm install

This is an issue of the build script, three persons tested now with a clean and fresh checkout. If we run normal npm install, it's included, if we do a php build/build.php the charset is not included.

So the build script is broken and the mentioned fix did not fix it.

This can be close since #43207 is merged