656882 - If first font in family is present on system but blocked by permissions, no fallback font is used

Status: RESOLVED DUPLICATE of bug 1412090

(Core :: Layout: Text and Fonts, defect)

Description

[Lesley Lutomski]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

A drop-cap effect on this site uses a font-family consisting of an uncommon font (ChromaSSK), followed by several common serifed fonts.  If ChromaSSK is available, Firefox displays it.  If it is not on the system, Firefox displays a serifed font as expected.  If it is present in a system folder which Firefox does not have permission to access, no font is displayed, even though all the serifed fonts listed are available.  The coloured background and border of the drop-cap appear with no letter inside. 

Reproducible: Always

Steps to Reproduce:
1. View site without ChromaSSK.  Drop-cap displays in alternative serifed font.
2. Install ChromaSSK in new folder inside fonts folder.  Drop-cap displays in ChromaSSK
3. Set access permissions on new folder to "none".  Drop-cap does not display at all.




It's unlikely that many people will be affected by this, but Firefox should default to an alternative font if the first is not available.

I have not had an opportunity to test this on any system other than Linux.

Comment 1

[:aceman]

Where can I get this font?

Comment 2

[Jonathan Kew [:jfkthame]]

It seems strange that a font inside a folder with no access permission should affect Firefox at all - I wonder if this reflects a shortcoming of fontconfig, if it's enumerating fonts as being available when in fact they are not.

Just wondering, is the "inaccessible" font included in the font list in the Preferences dialog?

Comment 3

[Lesley Lutomski]

(In reply to comment #1)
> Where can I get this font?

It comes with a Windows app.  However, the problem is not font-specific.  Use the same procedure to block Trebuchet MS, and the entire site vanishes.  Block the msttcorefonts folder, and most of the Web disappears.

Comment 4

[Lesley Lutomski]

(In reply to comment #2)
> It seems strange that a font inside a folder with no access permission
> should affect Firefox at all - I wonder if this reflects a shortcoming of
> fontconfig, if it's enumerating fonts as being available when in fact they
> are not.

The problem doesn't occur with Epiphany or Chromium.

> Just wondering, is the "inaccessible" font included in the font list in the
> Preferences dialog?

I'll try to test this with a new font; the list includes all fonts that have been available, even if they're currently blocked.

Comment 5

[Lesley Lutomski]

(In reply to comment #4)
> (In reply to comment #2)
> 
> > Just wondering, is the "inaccessible" font included in the font list in the
> > Preferences dialog?
> 
> I'll try to test this with a new font; the list includes all fonts that have
> been available, even if they're currently blocked.

I've now tested this with a new font which I know has never been on the system before.  Once the system has been restarted, the font does appear in the Preferences dialogue, even though it is not accessible.  The font is also listed by most other apps, but not all.  (LibreOffice does not include it.)

Comment 6

[:aceman]

Actually, blocking /usr/share/fonts/TTF while FF is running makes all its UI texts disappear :) Ok, I will have to make my own testfile referencing e.g. Trebuchet MS.

Comment 7

[:aceman]

Attachment: This is a reduced testcase using "Trebuchet MS" font.

Comment 8

[:aceman]

With the attached file I can reproduce it with
Mozilla/5.0 (X11; Linux i686; rv:5.0a2) Gecko/20110514 Firefox/5.0a2 ID:20110514042002

The Trebuchet MS files are inaccessible like this:
-rw-r-----  1 root root  123096 sep 19  2010 trebucbd.ttf
-rw-r-----  1 root root  131188 sep 19  2010 trebucbi.ttf
-rw-r-----  1 root root  139288 sep 19  2010 trebucit.ttf
-rw-r-----  1 root root  134108 sep 19  2010 trebuc.ttf

Firefox should then use Georgia or Times new roman (which I both have) or serif (DejaVu Serif or Arial).

I have restarted Firefox before making the test (and after blocking the files) but I have not restarted the X server.

Comment 9

[:aceman]

I can also confirm the problem does not exist on Opera 11.10 and Chrome 10. They render the letter I using some font, but I can't say optically which one it is. Opera even produces "open: permission denied" messages in the terminal whenever it tries to draw the letter with the correct font (which it does even when hovering the mouse over it).

Comment 10

[Karl Tomlinson (:karlt)]

Yes, I agree it would make sense to fall back to another font.

However, this sounds like a use case fontconfig was not intended to address.
If the font is not readable by a user then fontconfig should not be making information about that font available to the user (or fontconfig should not be configured to read that font).

Is there a good reason to support such a setup?

What do other GTK/Pango apps do when the default UI font is not accessible?

Comment 11

[:aceman]

Do Epiphany, Chrome and Opera NOT use fontconfig so they are not affected?

The UI font in comment 6 was a sideways experiment and not the exact issue of this bug (permission changes while FF is running are probably harder to avoid).

Comment 12

[Karl Tomlinson (:karlt)]

It's possible to check that we can read the font when we ask fontconfig about character support.  The code currently assumes that if fontconfig says it's available then it is available.  Additional checks may slow things down (disk access), and I'm not clear why supporting such a setup is important.

Comment 13

[:aceman]

Maybe fontconfig uses just the fontcache files created at font install time that are created under root, so all fonts are accessible and listed in the cache. If fontconfig instead of firefox would check accessibility at runtime, it would probably create the same slowdown. However it could store the accessibility in the cache beforehand. May be a tip for fontconfig developers. Is anybody in contact with them?

However, on the firefox side, what is the current algorithm?
1. Fontconfig reports the font as available
2. FF draws the text (via pango?)
3. The font is not really accessible so nothing is drawn.
4. Here, does FF have any indication it failed? Then it could check for it and use other font. Or does pango return success and that is the problem?

Yes, the motivation for fixing this bug is not very high. This setup probably means broken install and shouldn't be very common. User who installs font manually and breaks permissions will probably know/remember (how) to check the files if the font does not show up in FF.

Maybe it is good for opera/chrome parity? They seem to have no problem taking the perf hit, even at each mouseover. It may not be that big if the results for each font file are cached in memory (not many files are used while FF is running) and the disk access may not be even relevant - FF will read in the font anyway so a perm check beforehand may not add any addition disk read in summary.

Comment 14

[Karl Tomlinson (:karlt)]

(In reply to comment #13)
> However, on the firefox side, what is the current algorithm?
> 1. Fontconfig reports the font as available
> 2. FF draws the text (via pango?)
> 3. The font is not really accessible so nothing is drawn.
> 4. Here, does FF have any indication it failed? Then it could check for it
> and use other font.

That's basically it.  I assume there is indication that is as failed, but it's late in the process so it would be complex to back up and start again.

It would be easiest to check at 1 (after using fontconfig).

> It may not be that big if the
> results for each font file are cached in memory (not many files are used
> while FF is running) and the disk access may not be even relevant - FF will
> read in the font anyway so a perm check beforehand may not add any addition
> disk read in summary.

Yes, it should be possible to do in a way that doesn't increase access too much.

Comment 15

[Kevin Chadwick]

There is another test case that means no text is displayed by firefox whereas other browsers fallback to the next available preferred font. 

Which is if you mistype or remove a letter (testing) from a font name inside the @fontface { braces }.

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Kevin Chadwick from comment #15)
> There is another test case that means no text is displayed by firefox
> whereas other browsers fallback to the next available preferred font. 
> 
> Which is if you mistype or remove a letter (testing) from a font name inside
> the @fontface { braces }.

That sounds like a different issue (this bug specifically relates to file permissions), so please file it as a separate report. And a testcase that shows the problem you're describing would be helpful.

Comment 17

[Jonathan Kew [:jfkthame]]

A change that I believe should resolve this issue was included in the patches recently landed in bug 1412090. As such, I think this should no longer be reproducible with the latest Nightly.

:aceman, would you have a chance to test this and confirm whether it is now fixed? Thanks!

Comment 18

[:aceman]

Jonathan, looks good to me.
I removed the access to the Trebuchet MS fonts for the attached test case. Restarted TB and loaded the test file.
In FF 57 the 'I' using that font wasn't displayed.
In FF 70 and newer the 'I' is using the next font in the list, i.e. Georgia.

Comment 19

[Jonathan Kew [:jfkthame]]

OK, thanks for testing. Closing this as a dupe of bug 1412090. (That was filed about sandbox-related failures, but the issue was basically the same - inability to access the file for a font that we thought we could use.)

Comment 20

[:aceman]

Thanks.