Strange/Weird characters on refresh (Self-hosted CSS compiled from SCSS)

[templeman15]

Describe the bug
On random page loads or refreshing of page strange characters are displayed instead of the font awesome icons. Seems to very closely related to #15010 & #17611. However, it happens when using both fa classes and setting the content manually in css.

There is no trace of FA4 in the project.

To Reproduce

SCSS:

Expected:

Actual:

Expected behavior
Expected behavior is that the font awesome icons would display correctly.

Version and implementation
Version: Font Awesome Pro 5.14.0
Browser and version: Google Chrome 88.0.4324.150
OS: Mac OS 10.15.7

• SVG with JS
• Web Fonts with CSS
• SVG Sprites
• On the Desktop

Bug report checklist

• I have filled out as much of the above information as I can
• I have included a test case because my odds go way up that the team can fix this when I do
• I have searched for existing issues and to the best of my knowledge this is not a duplicate

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

Are you using self-hosted icons?

[templeman15]

Hi!

Thanks for being part of the Font Awesome Community.

Are you using self-hosted icons?

@tagliala yes we are! Thanks for the quick response :)

[tagliala]

Could you please try with the Pro CDN (not the kit, just the link to the plain css) and attempt to reproduce?

https://fontawesome.com/account/cdn

[tagliala]

Hi @templeman15

SCSS:

I just read and realised that it was a screenshot of the SCSS, and that doesn't help. Any chance to get a look at the CSS output served to the browser by your application?

According to the Sass library used by your application, you may have wrong CSS results:

[templeman15]

Hello @tagliala!

Here is the output served from the app (this is when the page loads correctly):

Here is the output css from the browser (this is when the strange character occurs):

[tagliala]

Ok, thanks.

Please switch to a different Sass implementation, make sure that your CSS output contains properly encoded characters

Meanwhile, closing here

[dkniffin]

@tagliala I am also seeing this behavior intermittently.

Can you clarify: is there an issue using fontawesome with dart-sass?

[dkniffin]

After some more investigation, this might be due to us setting $fa-font-display: swap, as touched on in #14387

[tagliala]

Can you clarify: is there an issue using fontawesome with dart-sass?

Not with Font Awesome. There are some issues with escaping with some versions of Dart Sass, please take another look at #17644 (comment)

There is no Font Awesome involved in this simple snippet:

.search-icon {
    &::before {
        content: "\f002";
    }
}

If the content is compiled into content: "";, then you may experience issues and I advise to double check the output. It should look like this in the output CSS:

Font-Awesome/css/fontawesome.css

Lines 3396 to 3397 in fcec2d1

	.fa-search:before {
	content: "\f002"; }

After some more investigation, this might be due to us setting $fa-font-display: swap, as touched on in #14387

You should not use that value for Font Icons: GoogleChrome/lighthouse#10127

[tagliala]

Hi @dkniffin

I've investigated and

Can you clarify: is there an issue using fontawesome with dart-sass?

Yes, there might be, in the case that a Font Awesome SCSS compiled to CSS with Dart Sass or Ruby Sass is not correctly interpreted as UTF-8 by the browser.

Although this may be considered a browser issue, I think that we should do our best to prevent it and provide ASCII output.

This will be hopefully fixed (again) in FA v6. I'm going to reopen this issue for tracking purposes

Since this will be a breaking change in v5, so I don't know what the team will decide.

The workaround is to override all the $fa-var-* variables in _variables.scss and the fa-content mixin from _mixins.scss

Ref:

• Add ASCII output support sass/dart-sass#568 (comment)
• Add ASCII output support sass/dart-sass#568 (comment)

Reference fix:

/* _mixins.scss */
@function fa-content($fa-var){
  @return unquote("\"") + unquote(str-insert($fa-var, "\\", 1)) + unquote("\"");
}

/* _variables.scss */
$fa-var-500px: f26e;

[tagliala]

The breaking change happened between dart-sass 1.10.4 and 1.11.0, but I can't bisect to the specific change because I do not have a proper dart build system.

Ruby Sass 3.7.4 is also affected and the breaking change happened between 3.6.0 and 3.7.0

SassC 2.4.0 is not affected

I guess this is the change: https://github.com/sass/sass/blob/master/accepted/identifier-escapes.md

Ref: sass/dart-sass#427 sass/ruby-sass#90

[tagliala]

Solution

if you have PUA codes (e.g., content: "" instead of content: "\f26e") in the output CSS, check that:

1. The served CSS file starts with @charset "UTF-8";; AND
2. The HTML file referring the CSS has the <meta charset="utf-8"> meta tag

#14660 (comment)

⚠️ update

Unfortunately this is not enough. It may fix 99% of the cases, but not 100%

[pydolan]

FWIW, I still see the odd characters with FA 5.14.0 5.15.3 (free) on a site with <meta charset="utf-8"> in the header. I haven't tried adding @charset to the CSS file, but that's on my TODO list. (I'm seeing it very intermittently on Chrome 90.x on Mac Big Sur)

With disclaimer about my limited browser internals knowledge, could it be a timing issue, where the font svg/wolff/ttf file isn't loading in time before the HTML renders the page?

[tagliala]

I don't know and I don't think so. <meta charset="utf-8"> should be the first tag in <head>

Will try to simulate this

[Arecsu]

I had this problem for so long and apparently I got rid of it by adding @charset "UTF-8"; at the beginning of my CSS file as suggested above. I already had <meta charset="utf-8"> in the html head, but seems like it wasn't enough.

Disclaimer: I don't use FontAwesome. I'm using the Inter font with their CSS import rules and CDN. I was searching about the issue and ended up here. Placed it right at the beginning of my CSS, just before the import font url.

Tested it plenty of times with different scenarios and I don't get the weird characters anymore. Everything works great.

[tagliala]

I had this problem for so long and apparently I got rid of it by adding @charset "UTF-8"; at the beginning of my CSS file as suggested above. I already had in the html head, but seems like it wasn't enough.

Thanks for this heads-up

[mayankchd]

We had this problem too, investigated a bit and then figured out that this problem started happening after we switched to dart-scss. Looks like dart-scss by default in prod mode removes the @chatset. This issue in sass-loader has a solution

[viniciusdeliz]

I also have 1.49.0 and I'm experiencing the bug too.

@brokensourcecode Have you found a way to fix this bug on our end?

Any luck with the 1.54.0 update in sass? The change appears to be the same of the 1.39.0 that was supposed to fix this, but maybe it works this time? https://github.com/sass/dart-sass/blob/main/CHANGELOG.md#1540

[tagliala]

Any luck with the 1.54.0 update in sass?

There is a partial fix in 1.38.0, as per #17644 (comment)

I can confirm that in 1.55.0 this issue has been partially fixed, in the meaning that codes in the private area are correctly escaped, letters and numbers aren't (would this be a problem? 🤷🏻‍♂️), and I can't see unescaped unicode characters in the output CSS, so the @charset rule is not being emitted

$ npx sass --version
1.55.0 compiled with dart2js 2.18.1
$ npx sass node_modules/@fortawesome/fontawesome-free/scss/fontawesome.scss

Partial output:

.fa-at::before {
  content: "\@";
}
/* ... */
.fa-0::before {
  content: "\30 ";
}
/* ... */
.fa-p::before {
  content: "P";
}
/* ... */
.fa-snowflake::before {
  content: "\f2dc";
}

Anyway, adding the @charset rule does not always work, in the meaning that sometimes you can still experience this issue (ref #18775), and, in addition to that, some upstream minifiers on top of Sass may decide to strip the rule out (webpack-based bundlers may do that), so probably a fix on Font Awesome is still needed for this issue

[Rezyan]

I also have 1.49.0 and I'm experiencing the bug too.
@brokensourcecode Have you found a way to fix this bug on our end?

Any luck with the 1.54.0 update in sass? The change appears to be the same of the 1.39.0 that was supposed to fix this, but maybe it works this time? https://github.com/sass/dart-sass/blob/main/CHANGELOG.md#1540

@viniciusdeliz I updated sass to version 1.54.0 on July 30th (currently my version is 1.55.0), and since then I've already encountered the weird characters on refresh, several times, randomly. So, on my side, the issue is still not fixed, but it seems that the problem occurs less often than before (maybe it's just an impression).

Anyway, adding the @charset rule does not always work, in the meaning that sometimes you can still experience this issue (ref #18775), and, in addition to that, some upstream minifiers on top of Sass may decide to strip the rule out (webpack-based bundlers may do that), so probably a fix on Font Awesome is still needed for this issue

@tagliala I agree with you: a Font Awesome's fix is still needed for this issue. 👍

[domenkozar]

I've hit this one using parcel: parcel-bundler/parcel#8713

[domenkozar]

I noticed that the css file doesn't get interpreted as css, so I investigated deeper into it. Opening up the debugger tools reproduced it consistently, so that was the first clue.

I had a theory that content-type: text/css; charset=utf-8 should be set as the header, which wasn't the case when I was serving files from nginx.

Following nginx.conf in the http section helped:

            source_charset utf-8;
            charset utf-8;
            charset_types text/html text/xml text/css text/plain text/vnd.wap.wml application/javascript application/rss+xml;

Now https://cachix.org will finally not get garbled fonts 🚀

[florent-cdl]

Found that post that was exactly my problem : encoding mixin error with libsass
sass/libsass-net#24
The workaround work great
@mixin pseudoFontIcon($content) {
content: #{"""+$content+"""};
}
a:before {
@include pseudoFontIcon(\e003); // without single/double quotes here
}

[magynhard]

For others, facing the same issue:

The problem with displaying the icons incorrectly when contained in unicode characters is Chrome related and happens only in Chrome and other Chromium based browsers (e.g. Edge or Vivaldi). I could not reproduce it on Firefox or Safari.

It is not related to FontAwesome, it is related to all Iconfonts using unicode. (Im my case my own font)

It can even be reproduced regularly the following way:

• Open your browser
• Open your website
• Open Chrome Dev Tools (F12)
• Reload Page (only F5 or Reload button, not Force Reload)
• Icons are displayed incorrectly

It works only once, if you want to repeat, you need to close the developer tools, reload the page, then reopen the developer tools again and reload again.

It seems, that chrome does not check or detect the format of the CSS correctly when the page is reloaded with developer tools open at the first time.

For me, the best solution was - as mentioned by others before - to add

@charset "UTF-8";

at the beginning(!) of the .css file to workaround the Chromium engine bug.

[tagliala]

Just to mention (again) that adding @charset "UTF-8"; will not fix 100% of the cases

I suggest to consider also changing response header via nginx or whatever proxy server: #17644 (comment)

[magynhard]

If using escaped utf8 characters beginning with \f adding the charset to the css header seems to work always, but maybe not when having the real utf8 characters inside the css. I think changing the web server header to fix this is no good solution. In my opinion you should convert to escaped characters and add the charset. Especially, when the developer has no option or no easy way to configure the webserver. So you are independent of whatever webserver is used and have the control in your web project instead on the webserver layer.

[tagliala]

In my opinion you should convert to escaped characters and add the charset

I'm 100% for this solution, and I think that FA should output escaped chars, but unfortunately it's a breaking change :(

Upgrading to dart sass > 1.55 should also help (or maybe even fix)

[nsunga]

Solution

if you have PUA codes (e.g., content: "" instead of content: "\f26e") in the output CSS, check that:

1. The served CSS file starts with @charset "UTF-8";; AND
2. The HTML file referring the CSS has the <meta charset="utf-8"> meta tag

#14660 (comment)

⚠️ update

Unfortunately this is not enough. It may fix 99% of the cases, but not 100%

hello @tagliala !

so sorry to bring up such an old comment

I did read the update, but with this "fix" does that mean the minified code results in the unicode string (ie. "\f26e")?

at the moment, the minified css I have are all PUA (Private Use Area) codes even with the "fix"

[tagliala]

I did read the update, but with this "fix" does that mean the minified code results in the unicode string (ie. "\f26e")?

No, if you want a fix like that, it is a little bit more complicated at the moment and it will require a new fix after each update, please check the comments here: diowa/ruby3-rails6-bootstrap-heroku#540

[lindalinya]

Hey guys, we don't use font-awesome but we came across your issue while trying to solve this problem with our own library so how you realized sass is decoding the Unicodes in build time and causing broken content to the classes

we work around this by importing the CSS icons files directly to js and skipping the sass-loader.

before: after:

Actually, this case is not from sass-loader but dart-sass. I have looked up many, many issues about this case, which are all over the major open-source warehouses such as sass, sass-loader, and so on.

The source of the problem is not the sass-loader, the sass-loader just calls the sass command, so the source of the problem is the default encoding of dart-sass (you can get this result just with sass-loader and file-loader), which stubbornly encodes characters that do not need to be encoded. So "\xxx" in our code is translated into a garbled character after dart-sass compilation.

Unfortunately, dart-sass could have had an elegant solution to this problem, however, their developers were so stubborn that they believed their default coding could not be changed. They think this effect is so great that they act like bandits and demand that person who asked the question provide stable replication steps for an occasional bug.

Guess the ultimate source of this problem can actually be attributed to the browser, the browser for the CSS encoding guess error, resulting in even if you have added html encoding and CSS charset, the font icon parsing still occurs problems.

The final solution, as this man says, is to Change your sass file to a CSS file. Extract all CSS styles that contain Unicode characters into a CSS file, not a Sass file. The CSS file does not need to go through the sass-loader, so the stubborn dart-sass cannot corrupt it

[nsunga]

Update on my end:

I ended up using a postcss plugin - https://github.com/lcoronelp/postcss-sass-unicode

I will say that its not great, though because this is what looks like is happening:

1. dart-sass is taking the unicode characters and encoding them to the square things []
2. then, the postcss plugin takes the square things and then decodes them back to the unicode characters in the final css

So now when the browser loads in the css, it doesnt have to do its decoding for whatever the square [] is - its just reading the value.

Until theres a popular solution, ive just been using the above plugin for now

[lindalinya]

Update on my end:

I ended up using a postcss plugin - https://github.com/lcoronelp/postcss-sass-unicode

I will say that its not great, though because this is what looks like is happening:

1. dart-sass is taking the unicode characters and encoding them to the square things []
2. then, the postcss plugin takes the square things and then decodes them back to the unicode characters in the final css

So now when the browser loads in the css, it doesnt have to do its decoding for whatever the square [] is - its just reading the value.

Until theres a popular solution, ive just been using the above plugin for now

Maybe you can try my idea if your font icon related styles are all in a sass file. Just change this sass file to a CSS file to make it escape dart-sass

[damirbogdanov]

Update on my end:

I ended up using a postcss plugin - https://github.com/lcoronelp/postcss-sass-unicode

I will say that its not great, though because this is what looks like is happening:

1. dart-sass is taking the unicode characters and encoding them to the square things []
2. then, the postcss plugin takes the square things and then decodes them back to the unicode characters in the final css

So now when the browser loads in the css, it doesnt have to do its decoding for whatever the square [] is - its just reading the value.

Until theres a popular solution, ive just been using the above plugin for now

thank you @nsunga, this approach seemed to help in our case and helped to resolve an issue

[vineeth-ktp]

Issue is often(50% of the time) occurring with Mac Chrome. I have tried adding charset, but it still fails. The icons gets added by CMS and we don't have a way to determine which of them to preload. We are using sass and not with dart as it is not supported by CMS. Is there any other solution suitable here?

[tagliala]

We are using sass and not with dart as it is not supported by CMS

This is supposed to happen with self-hosted css files compiled from Sass, so it should mean that user have the ability to make changes to the toolchain used to compile the css output.

You can:

• Downgrade to an older version of Sass not affected by the issue, ref: Strange/Weird characters on refresh (Self-hosted CSS compiled from SCSS) #17644 (comment)
• Fix the provided css by transforming some values. Steps at Experimental/fontawesome css unicode fix diowa/ruby3-rails6-bootstrap-heroku#540

[viniciusdeliz]

For fellows using webpack and facing this issue, I've realized that while on localhost my stylesheet always had the icons in place. So I found that in the stylesheet of my built application I had the following output:

So testing a bit of options, I figured that the culprit of my setup was the sass-loader set for .scss files. So on my webpack.config.js for my /\.scss$/ rules, I included the following sassOptions entry in the options object for the sass-loader:

{
    loader: 'sass-loader',
    options: {
        sassOptions: {
            outputStyle: 'expanded',
        },
    },
},

Now the stylesheet output for my build is the following:

Hopefully this can help someone!