Firefox cannot load user-local fonts under Windows 10 for network-loaded pages
Categories
(Firefox :: Untriaged, defect)
Tracking
()
People
(Reporter: mqudsi, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Steps to reproduce:
This is pursuant to my research into #1535051. Under Windows 10 17763, the ability for fonts to be installed on a per-user basis was finally added. These fonts live under %localappdata%\Microsoft\Windows\Fonts.
Firefox can see the existence of these fonts in its own chrome (e.g. the default font settings) and loads them OK when the requested page is loaded locally from disk (file:///), but when the page is loaded over the network the fonts fail (Firefox does not find them when attempting to resolve a font-family declaration).
To test, install a font locally to the user-specific font folder under Windows 10 17763. Make sure the font is not also installed to the system-wide font folder C:\Windows\Fonts. Reference the font in an HTML document opened locally, then open the same HTML file over the http protocol (via a local webserver).
Actual results:
The page loaded locally via file:/// renders user-local fonts correctly. The page loading pages remotely/over the network via the http:// protocol is unable to match the fonts in question.
Expected results:
Both the page loaded via file:/// and the page loaded via http:// should be able to resolve user-local fonts.
(Additionally, if you have a user-local font set as the default monospace font and view the source for both rendered pages, the view-source:file:/// page will use the correct font, the view-source:http:// will use the default monospace font (Courier Font) despite the user explicitly selecting something else.
|
||
Comment 1•6 years ago
|
||
Interesting. This sounds like it could be related to the content-process sandboxing. Does the same problem occur with current Nightly versions? (https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly) I seem to recall there was some recent change in this area, but don't remember the specific bug.
|
|
||
Comment 2•6 years ago
|
||
Ah, found the previous report. I think this is bug 1512731; in which case it should be fixed in Firefox 66 or later. Could you please confirm if the problem is resolved for you in newer releases?
|
Reporter | |
Comment 3•6 years ago
|
||
It is indeed fixed in nightly. I wasn't able to find anything by searching myself before posting, but thank you!
|
|
||
Comment 4•6 years ago
|
||
OK, thanks for checking; in that case I think we can close this.
Description
•