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

Mojibake instead of glyphs #5884

Closed
3 of 7 tasks
akhenry opened this issue Oct 18, 2022 · 7 comments · Fixed by #7073
Closed
3 of 7 tasks

Mojibake instead of glyphs #5884

akhenry opened this issue Oct 18, 2022 · 7 comments · Fixed by #7073

Comments

@akhenry
Copy link
Contributor

akhenry commented Oct 18, 2022

Summary

Strange characters are sometimes observed in place of glyphs in Open MCT after a new build is generated.

One theory I have is that for whatever reason there's a mismatch between the unicode characters specified in constants.scss and the unicode characters used in the font files. I suspect that one is being cached by Chrome, and the other is not. When we rebuild our fonts and then deploy a new version this mismatch causes unexpected characters to be rendered in place of our glyphs. This continues until either the cache is completely cleared (and Chrome can cache quite aggressively), or the cached version expires and is eventually replaced by the newer version.

Expected vs Current Behavior

Open MCT glyphs should be rendered, not mojibake.

Steps to Reproduce

Unknown at this stage.

Environment

  • Open MCT Version: 2.0.5
  • Deployment Type: VIPER Prod.
  • OS: Mac OS 12.6
  • Browser: Chrome 106.0.5249.119

Impact Check List

  • Data loss or misrepresented data?
  • Regression? Did this used to work or has it always been broken?
  • Is there a workaround available? - Yes, empty cache and hard reload
  • Does this impact a critical component?
  • Is this just a visual bug with no functional impact?
  • Does this block the execution of e2e tests?
  • Does this have an impact on Performance?
@unlikelyzero
Copy link
Collaborator

@akhenry akhenry added this to the Target:3.1.0 milestone Aug 24, 2023
@akhenry
Copy link
Contributor Author

akhenry commented Sep 15, 2023

I'm no longer convinced it's a simple caching issue, based on some observations:

  1. We are loading stylesheets dynamically by inserting a <link> element in the <head> block of the page. This happens immediately upon installing the plugin, which means it occurs before the document (and indeed the head element) has finished rendering. This might be problematic.
  2. When the mojibake appears, there is NO corresponding network request for CSS AT ALL in the network tab. This is truly bizarre, even cached assets have a corresponding request in the network tab that is resolved from the cache.

I'd like to explore deferring the loading of the stylesheet to see if this fixes the mojibake.

@akhenry
Copy link
Contributor Author

akhenry commented Sep 18, 2023

After some more investigation, I believe that this is actually an issue of encoding. Adding an encoding preamble to the stylesheet seems to resolve the problem.

@charset "UTF-8";

Even though we include a meta tag that sets the encoding to utf-8 for whatever reason Chrome seems to sometimes revert to some other encoding when loading the stylesheet. Again it could be because we are trying to load before the HEAD element has finished loading.

I have a branch that modifies our build tooling to automatically prepend this to our stylesheets that I will push for testing.

@akhenry akhenry mentioned this issue Sep 20, 2023
15 tasks
@akhenry
Copy link
Contributor Author

akhenry commented Sep 20, 2023

Testing Instructions

  1. Open dev tools
  2. Make sure "Disable Cache" is not checked
  3. COMPLETELY quit Chrome
  4. Load Open MCT
  5. Empty cache and hard reload
  6. Make sure "Disable Cache" is not checked.
  7. Hit refresh several times in quick succession. Make sure this is a regular refresh (not an empty cache refresh)
  8. Verify that mojibake does not appear.
  9. Repeat steps 3 - 8 another two or three times.

@rukmini-bose
Copy link
Contributor

Verified Testathon 9/22/2023

@khalidadil
Copy link
Contributor

khalidadil commented Sep 22, 2023

Verified in Testathon on 09/22/2023. I followed the instructions, refreshing 10 times in succession and wasn't able to see the mojibake.

@unlikelyzero
Copy link
Collaborator

Verified Testathon 9/22/2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants