Strange/Weird characters on refresh (CSS / Sass / Self-hosted)

[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
• [x] Web Fonts with CSS
• [ ] SVG Sprites
• [ ] On the Desktop

Bug report checklist

• [x] 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 https://github.com/FortAwesome/Font-Awesome/issues/17644#issuecomment-781647877

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:

https://github.com/FortAwesome/Font-Awesome/blob/fcec2d1b01ff069ac10500ac42e4478d20d21f4c/css/fontawesome.css#L3396-L3397

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:

• https://github.com/sass/dart-sass/issues/568#issuecomment-770105804
• https://github.com/sass/dart-sass/issues/568#issuecomment-562086079

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

https://github.com/FortAwesome/Font-Awesome/issues/14660#issuecomment-790475966

⚠️ 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

[tagliala]

Unfortunately this did not meet the 6.x milestone because of backward compatibility.

This should only affect some users using both SCSS and dart-sass.

I suggest to double check that both HTML and CSS (HTML is not enough) files have the correct charset. Some build system like webpack may strip out the @charset from the compiled css. You may want to use another plugin to write it back in the file

[danon]

[...] This issue in sass-loader has a solution

More of an workaround, since it suggests disabling compression. Hardly a solution.

[tagliala]

This should have been fixed in dart-sass's 1.38.0 release

https://github.com/sass/dart-sass/releases/tag/1.38.0

sass/dart-sass#1430

dart-sass users, please give it a try

I'm personally not happy with the result, I would like to see this "fixed" in FA, so I'm leaving this open for the moment

[danon]

@tagliala We're using dart-sass version 1.49 and the bug still happens sometimes.

[tagliala]

@Danon could you please provide an excerpt from the output CSS file where icons are defined?

I'm interested in knowing if the output is using unicode characters ("") or their escaped form ("\f26e")

[danon]

@Danon could you please provide an excerpt from the output CSS file where icons are defined?

I'm interested in knowing if the output is using unicode characters ("") or their escaped form ("\f26e")

Can't since it happens randomly. About once a week for me.

[tagliala]

@Danon sorry, maybe I wasn't clear

I've asked an excerpt of the CSS file containing the rule of a Font Awesome icon taken from the website where you are experiencing the bug

In other words, the following code:

https://github.com/FortAwesome/Font-Awesome/blob/307f2c15e2d3bdf465b43df0d1486dcd249df2a1/css/fontawesome.css#L547-L548

but taken from your CSS

[Rezyan]

@tagliala I'm using Font Awesome with dart-sass to compile the SCSS files. And of course, I'm experiencing the same issue, randomly. For some reason, the issue happens more often when the web console is open or being opened.

Here is the code you asked @Danon for, but from my CSS output:

.fa-anchor::before {
    content: "";
}

Screenshot:

Hope this can help.

[tagliala]

Yes, thanks.

We are trying to sort this out without breaking backward compatibility but it is a little bit trickier

As per dart sass, I can see that this has been partially fixed in 1.38.0, please make sure that you are using >= 1.38.0

There is also a workaround, but we don't know yet if it will fix 100% of the cases and requires effort on developer side. If you want to test, I've provided a step-by-step guide here: https://github.com/FortAwesome/Font-Awesome/issues/18775#issuecomment-1073217558

[Rezyan]

We are trying to sort this out without breaking backward compatibility but it is a little bit trickier

There is also a workaround, but we don't know yet if it will fix 100% of the cases and requires effort on developer side. If you want to test, I've provided a step-by-step guide here: https://github.com/FortAwesome/Font-Awesome/issues/18775#issuecomment-1073217558

I'm not in a hurry, I'll wait for this issue to be fixed by Font Awesome. The issue happens quite rarely, and you just have to reload the web page again to temporarily fix it.

As per dart sass, I can see that this has been partially fixed in 1.38.0, please make sure that you are using >= 1.38.0

I'm using the 1.49.9 version of sass/dart-sass. So, I guess their partial fix doesn't really work for me!

{
	"devDependencies": {
		"sass": "^1.49.9"
	}
}

[danon]

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?

[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?

Not really, but you can try to programmatically add the rule @charset "utf-8"; at the VERY TOP of your CSS output files (AFTER the processing of dart-sass). You may use something like gulp-header or webpack (with the BannerPlugin).

By the way, don't forget to put the HTML tag below inside the <head> tag:

<meta charset="UTF-8">

[tagliala]

Hi @BrokenSourceCode ,

as per my understanding, @charset "utf-8"; and <meta charset="UTF-8"> are not enough to fix 100% of the cases. Ref: #18775

@GameCharmer is testing a fix that we can implement without breaking backward compatibility (on expense of compile time and scss source size), so I would like to ask if there are any news (but I'm assuming no news is good news)

[GameCharmer]

@tagliala So far so good! We haven't received a single message about it from our users, and none of the development team has ran into it since implementing your fix. You definitely nailed it! :D

[OwenPattison]

@GameCharmer @tagliala This sounds great thanks for the continued effort.

Is there a timeline for this release?

[robmadole]

No ETA yet. @tagliala has done a lot of the ground work here but we'll need to make sure we've got this nailed down before we release it.

[tagliala]

we'll need to make sure we've got this nailed down before we release it.

Agree. An application I maintain suffers of the same issue, but I would definitely avoid such a change if it is not going to fix 100% of the cases.

More feedback would be welcome.

Here it is a guide on how to test the workaround manually:

I've tried to provide a step by step fix here: https://github.com/diowa/ruby3-rails6-bootstrap-heroku/pull/540

This is based on Font Awesome Free, so steps for Pro should be a little bit different

At the end of the procedure, double check that variables in the output css have the proper escaped entities:

• ✅ .icon::before { content: "\f26e"; }
• ❌ .icon::before { content: ""; }

NOTE: This change will make harder to update Font Awesome

Feel free to ask any question

[nirt04]

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: