percy-cypress: Percy-Cypress v3 does not load fonts

We are trying to migrate one of our projects to the new Percy-Cypress v3, and we have problems with custom fonts not being rendered on the Percy screenshots.

Sample, with differences highlighted:

Sample, with no highlights:

From debug logs, I see that font files (woff and ttf) are being loaded -

[percy:core:discovery] Handling request for http://localhost:8080/fonts/CustomSansTTRegular.woff2 (42ms)
...
[percy:core:discovery] Handling request for http://localhost:8080/fonts/CustomSansTTRegular.woff2 (17ms)
...
[percy:core:discovery] Processing resource - http://localhost:8080/fonts/CustomSansTTRegular.woff2 (4ms)
[percy:core:discovery] Making local copy of response - http://localhost:8080/fonts/CustomSansTTRegular.woff2 (5ms)
[percy:core:discovery] -> url: http://localhost:8080/fonts/CustomSansTTRegular.woff2 (1ms)
[percy:core:discovery] -> sha: b0bacf06b2e7a3e3fc672625c9aaff825ed79d754a174c0f352d68d10daf7397 (0ms)
[percy:core:discovery] -> filepath: /tmp/percy/b0bacf06b2e7a3e3fc672625c9aaff825ed79d754a174c0f352d68d10daf7397 (1ms)
[percy:core:discovery] -> mimetype: font/woff2 (0ms)

...

(in the following tests)
[percy:core:discovery] Handling request for http://localhost:8080/fonts/CustomSansTTRegular.woff2 (1ms)
[percy:core:discovery] Response cache hit for http://localhost:8080/fonts/CustomSansTTRegular.woff2 (1ms)

All that looks pretty legit, besides the duplicate “handling request” line. Yet, the screenshots are rendered with the default font.

Any idea what went wrong here? Are we missing any pieces in the migration process?

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 18 (8 by maintainers)

Most upvoted comments

We were able to isolate the issue to a combination of webpack-dev-server and file-loader. Our solution was to use url-loader instead of the file-loader with webpack-dev-server - that is, locally and in PR builds in CI. You can add one more recipe to your collection of the workarounds. Thank you for helping us to solve this mystery!

khitrenovich on Apr 16, 2021

@Robdel12 Build 9750416, snapshot 549314950 (or any other from that build). Thank you so much!

khitrenovich on Apr 8, 2021

Oh man, that is so rough. I wish this wasn’t so awful to debug! Thanks for that info, it does make me wonder if keeping the same setup & building as production would also fix the issue.

Local dev servers tend to do interesting things to assets in the name of reload-ability (like serve CSS as blob asset, for faster live reloads). This might be another one of those quirks 😫

Robdel12 on Apr 19, 2021

I’d expect that. 😄 CLI uses a very specific version of Chrome (and we change it manually – different from @percy/agent which changes Chrome under the hood as Puppeteer does, that causes a lot of issues for us in SDKs like this).

No updates here – this issue has been around since at least January (which predates CLI & existed in @percy/agent). The last time this was “fixed” we had a solid reproduction provided and it was due to the server serving Mojibaked responses of the fonts. So by the time Percy captured the request from Chrome, it was already corrupt. Nothing Percy’s SDK could do there. This looks exactly the same, except sadly it’s not http-server’s fault. We fixed it by not using http-server, since it was serving broken assets to Chrome.

My guess is this happens because the server & the version of Chrome. Unfortunately this is not easy to replicate, so having that solid replication would make this more solvable.

Robdel12 on Apr 15, 2021

I am seeing the same font loading issue in @percy/cypress @2.3.4

vdineva on Apr 8, 2021