Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 of 7 tasks
templeman15 opened this issue Feb 17, 2021 · 58 comments
Open
2 of 7 tasks
Assignees

Comments

@templeman15
Copy link

templeman15 commented Feb 17, 2021

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:
Screen Shot 2021-02-17 at 1 25 31 PM

Expected:
Screen Shot 2021-02-17 at 1 26 01 PM

Actual:
Screen Shot 2021-02-17 at 1 25 53 PM

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
Copy link
Member

Hi!

Thanks for being part of the Font Awesome Community.

Are you using self-hosted icons?

@templeman15
Copy link
Author

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
Copy link
Member

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
Copy link
Member

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:

image

@templeman15
Copy link
Author

Hello @tagliala!

Here is the output served from the app (this is when the page loads correctly):
Screen Shot 2021-02-18 at 1 49 52 PM

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

Screen Shot 2021-02-18 at 2 02 43 PM

@tagliala
Copy link
Member

Ok, thanks.

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

Meanwhile, closing here

@dkniffin
Copy link

@tagliala I am also seeing this behavior intermittently.

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

@dkniffin
Copy link

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

@tagliala
Copy link
Member

tagliala commented Feb 23, 2021

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:

.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
Copy link
Member

tagliala commented Mar 4, 2021

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:

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 tagliala reopened this Mar 4, 2021
@tagliala tagliala added this to the 6.0 milestone Mar 4, 2021
@tagliala
Copy link
Member

tagliala commented Mar 10, 2021

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
Copy link
Member

tagliala commented Apr 16, 2021

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%

@tagliala tagliala changed the title Strange characters on refresh - Font Awesome 5 Pro Strange/Weird characters on refresh Apr 16, 2021
@pydolan
Copy link

pydolan commented May 12, 2021

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
Copy link
Member

tagliala commented May 12, 2021

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
Copy link

Arecsu commented May 28, 2021

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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link
Member

tagliala commented Sep 27, 2022

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
Copy link

Rezyan commented Sep 28, 2022

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
Copy link

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

@domenkozar
Copy link

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
Copy link

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
Copy link

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
Copy link
Member

tagliala commented May 2, 2023

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
Copy link

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
Copy link
Member

tagliala commented May 2, 2023

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
Copy link

nsunga commented May 10, 2023

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
Copy link
Member

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
Copy link

lindalinya commented Jun 8, 2023

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: image after: image image

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
Copy link

nsunga commented Jun 8, 2023

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Member

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:

@viniciusdeliz
Copy link

viniciusdeliz commented Sep 1, 2023

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:

webpack-fa

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:

webpack-fa-sol (1)

Hopefully this can help someone!

thinkh added a commit to datavisyn/visyn_scripts that referenced this issue Mar 28, 2024
puehringer added a commit to datavisyn/visyn_scripts that referenced this issue Apr 3, 2024
Coming from datavisyn/reprovisyn#1665

### Developer Checklist (Definition of Done)

**Issue**

- [x] All acceptance criteria from the issue are met
- [ ] Tested in latest Chrome/Firefox

**UI/UX/Vis**

- [ ] Requires UI/UX/Vis review
  - [ ] Reviewer(s) are notified (_tag assignees_)
  - [ ] Review has occurred (_link to notes_)
  - [ ] Feedback is included in this PR
  - [ ] Reviewer(s) approve of concept and design

**Code**

- [x] Branch is up-to-date with the branch to be merged with, i.e.,
develop
- [x] Code is cleaned up and formatted
- [ ] Unit tests are written (frontend/backend if applicable)
- [ ] Integration tests are written (if applicable)

**PR**

- [x] Descriptive title for this pull request is provided (will be used
for release notes later)
- [x] Reviewer and assignees are defined
- [x] Add type label (e.g., *bug*, *feature*) to this pull request
- [x] Add release label (e.g., `release: minor`) to this PR following
[semver](https://semver.org/)
- [x] The PR is connected to the corresponding issue (via `Closes #...`)
- [x] [Summary of changes](#summary-of-changes) is written


### Summary of changes

- Add solution proposed by
FortAwesome/Font-Awesome#17644 (comment)


### Screenshots


### Additional notes for the reviewer(s)

-  
Thanks for creating this pull request 🤗
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests