System fonts are not used when remote fonts are blocked
WhyNotHugo opened this issue · 13 comments
Prerequisites
- I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
- This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
- This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
- I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
- The issue is not present after disabling uBO in the browser.
- I checked the documentation to understand that the issue I am reporting is not normal behavior.
I tried to reproduce the issue when...
- uBO is the only extension.
- uBO uses default lists and settings.
- using a new, unmodified browser profile.
Description
I have font awesome installed on my system (installed via apk add font-awesome).
If I enable Block remote fonts on uBlock origin, when I visit a website which uses FontAwesome, the remote font is blocked. However, the font available on my local system is not used either (the expectation is that it should).
On the other hand, if I visit a page which specifies this same font in a font-family without trying to load the font from a remote server, it is not blocked. E.g.: If I put this on an empty HTML page that doesn't load any custom fonts, it renders fine:
<div style="font-family: 'FontAwesome'"></div>This can be generalised to all fonts; if remote fonts are blocked, system fonts that are available are not used either.
It would seem that "block remote fonts" also blocks system fonts with a matching name.
A specific URL where the issue occurs.
https://vdirsyncer.pimutils.org/en/stable/
https://rust-lang.github.io/mdBook/Steps to Reproduce
- Install FontAwesome font on your system.
- Block remote fonts on uBlock origin
- Visit https://rust-lang.github.io/mdBook/
You can really use any other font to reproduce, you just have to install it first, and then visit a website using that font.
Expected behavior
Blocking remote fonts should not block system fonts.
Actual behavior
Blocking remote fonts blocks system fonts with the same name.
uBO version
1.56.0
Browser name and version
firefox-123.0-r3
Operating System and version
Alpine Linux Edge
This is not a uBO issue, the browser is the one picking which fallback fonts to use when webfonts are blocked.
The browser picks the correct font when uBlock is not involved.
The browser does not pick the correct font when uBlock is involved.
It sounds to me like the problematic factor is uBlock; what am I missing in this situation?
The browser picks the correct font when uBlock is not involved.
Because webfonts are not blocked and properly downloaded from the website?
If the remote site does not try to load the webfont, the browser will use the system one normally. Only when uBlock origin blocks the font does Firefox fail to load it.
If the remote site does not try to load the webfont
What do you mean by "not try"? If the font resource is in your browser cache, the browser won't try to fetch the resource and will use the cached instance.
Looks to me you are looking for the browser to use your system fonts if their name matches the webfonts of a site. You have to file an issue with browser developers. uBO has no knowledge of system fonts or anything outside its browser-assigned sandbox. Whatever happens when a webfont is blocked is dictated by the browser.
I'll rephrase: If the remote site does not include any reference to a remote font, the browser will use the system one normally. Example page that works fine:
<html>
<head></head>
<body>
<div style="font-family: 'FontAwesome'"></div>
</body>
</html>On a page which loads a remote font (e.g.: https://vdirsyncer.pimutils.org/en/stable/), uBlock origin blocks FontAwesome, and the system font is not used.
Looks to me you are looking for the browser to use your system fonts if their name matches the webfonts of a site.
Yes, this is what I want, and the browser does this by default. Try out the above HTML. I stops working when uBlock intervenes.
Maybe because the site actually smuggles js files as fonts (icons too as well), and maybe blocked scripts cause system fonts fail to load, or maybe some bug in uBO causes fail to detect resource types:
(also reminds: #2496)
The issue is that the webpage defines a FontAwesome as a webfont, and when that webfont is blocked, your browser won't try to fallback to a local font because it doesn't know that any of your local font is a match -- only you know this. Maybe asks the browser devs about this.
uBO doesn't know better either, it has no access to your system.
The only workaround I can think of for uBO is that whenever remote fonts are blocked for a given website:
Inject a CSS declaration to redefine @font-face declaration for FontAwesome to a packaged web_accessible_resources FontAwesome font file. Of course this is not a fallback to whatever system font you have installed, this is just not possible for uBO, no matter how you insist uBO should do it.
But doing the above is just for one specific font, this would open the door to having to endlessly fulfill requests to keep adding this font or that font. etc.
You might be able to solve this issue on your side by using user styles:
@font-face {
font-family: 'FontAwesome';
src: url('file:///path.to.your.fontawesome.file');
}Or from what I've read, maybe simpler:
@font-face {
font-family: 'FontAwesome';
src: local('FontAwesome');
}your browser won't try to fallback to a local font because it doesn't know that any of your local font is a match
The browser resolves the webfont fine for the following example:
<html>
<head></head>
<body>
<div style="font-family: 'FontAwesome'"></div>
</body>
</html>Firefox normally the browser tries fallback fonts. What you're saying is that if and only if uBO blocks a webfont with a matching name, then Firefox will not try fallback fonts?
I am saying that uBO doesn't know about system fonts. Wholly disable uBO and block the same URL with a hosts file and you will the same issue. I am repeating myself, but here I go: The issue is that the site defines a font face with a specific name, and a specific URL where to find that font face. The browser can't fetch the resource, then consider the font face to not have any definition.
You want the browser to fall back to the font on your system having the same name if the font resource for that font face can't be fetched. You need to ask the browser devs that you want this. uBO is not the browser, it can't do the powerful things you are asking it to do, it knows nothing about system font, doesn't have access to your file system, to your OS configs, etc.
Does it happen on Chromium too or not, maybe I'm wrong but maybe a duplicate of :