Requests to load fonts with wrong URL in Chrome/Edge

[k-risc]

We noticed 404 errors in the web server and application logs related to fonts. We use version 1.11.11

Expected Behavior

Fonts being requested from their correct location, e.g. https://www.example.com/fonts/font.woff2 or https://www.example.com/webfonts/font.woff2

Current Behavior

We use an MVC framework (CakePHP). When being on a page for a particular controller action, e.g. https://www.example.com/entities/view/1234, the requests to the fonts are built as https://test-www-newton.revantage.local/entities/fonts/font.woff2

Possible Solution

In Firefox (desktop), it works as expected. In Chrome (desktop and mobile/Android), as well as in Edge, these requests are generated.

Steps To Reproduce

These are particular to our web application, so I am not sure if the same happens if executed in another application under the same circumstances.

Additional Context

none

Your Environment

• html-to-image:. 1.11.11
• OS: Windows 11, Android 14
• Browser: Chrome/Edge

[biiibooo]

👋 @k-risc

Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[k-risc]

This might be related to CSP settings. I found errors in the dev console saying:
Refused to set the document's base URI to '<URL>' because it violates the following Content Security Policy directive: "base-uri ".

We use base-uri 'self'. The method resolveUrl() tries to set the <base> element's href in an on-the-fly document, so it can later retrieve the full path to the font file based on its relative path definition. It seems to be trying to set the href attribute to the full URL to the CSS file containing the rule, e.g. https://www.example.com/css/bundle.css?V=123456.

Firefox seems to accept that., but Chrome/Edge not. Setting the <base> element's href is then disallowed, and the full path to the font file that the code retrieves is based on the URL of the current document itself, e.g. https://www.example.com/entities/view/1234.

After adding 'https://www.example.com/css' explicitly to the CSP configuration, it worked.

I'll check if I find out more in regard to if and why the browsers are handling this differently.

[k-risc]

Indeed it was our CSP settings that caused this. Due to an error in the configuration they were actually not base-uri 'self', but 'none'. After fixing this, the fonts loaded fine.