fix(fonts): relative protocol urls

[florian-lefebvre]

Changes

• Closes Issues loading fonts from fontshare in Experimental fonts API #13754
• Some remote font providers return protocol relative URLs (starting with //), which are then considered absolute by the font fetcher and fails
• Now when we normalize remote font data, we default this kind of URL to https

Testing

Unit + manual

Docs

Changeset

[changeset-bot]

🦋 Changeset detected

Latest commit: ebbfd22

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

CodSpeed Performance Report

Merging #13765 will not alter performance

_{Comparing fix/fonts-absolute-url-check (ebbfd22) with main (0db39b0)}

Summary

✅ 6 untouched benchmarks

[ematipico]

Can you create a e2e test (or integration test), so we test if the font is correctly loaded? I'm not sure a unit test is enough here

[ascorbic]

I approved this before seeing Ema's request for changes

[florian-lefebvre]

@ematipico I don't think a e2e test is needed here. The way the fonts are architected allow to test every part in isolation with unit tests.

In this case, the bug is not that the font fetcher thinks the url is absolute when it's not (and fails). The bug is that the url it receives is incorrect. So I believe the test is actually fine since it makes sure this kind of url is handled earlier.

Let me know what you think!