Description
Most appropriate sub-area of p5.js?
- Accessibility
- Color
- Core/Environment/Rendering
- Data
- DOM
- Events
- Image
- IO
- Math
- Typography
- Utilities
- WebGL
- Build process
- Unit testing
- Internationalization
- Friendly errors
- Other (specify if possible)
p5.js version
2.x
Web browser and version
Chrome
Operating system
Github action runner
Steps to reproduce this
If you've submitted a PR before, you may have seen this visual test fail:
When it fails, we see it just using the default serif font rather than the Google Font.
Often just rerunning the CI jobs causes it to work. It'd be great to figure out exactly why this is flaky and see what we can do about it.
My current theory is this: when we load a font via a CSS file (as we are when we load a Google Font), there are potentially a lot of different font files referenced in it, and we pick what we think the most relevant one is to load. However, we also attach the whole CSS file to the page, so the other font options are still accessible to the sketch. But potentially the browser isn't adding those other fonts to document.fonts reliably until they are actually requested for use by something in the DOM or on the canvas, so when we immediately try to render using it, it's not present, but might be present if we waited for it to load and then rerendered. The main problem with this theory: why does rerunning the tests work, then, when it should be running in a fresh container with no history of the last run? Does it just happen to load fast enough sometimes?
There are two potential things we can do about this:
- Identify and fix the underlying cause of the flakiness and make it
awaitable - Figure out another way to test font weight usage in CSS fonts without this flakiness