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.

Where can I get this font?

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?

(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.

(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.

(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.)

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.

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.

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).

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?

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).

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.

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.

(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.

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 }.

(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.

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!