User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Android; Linux armv7l; rv:2.1.1) Gecko/20110415 Firefox/4.0.2pre Fennec/4.0.1 On the page https://linuxfr.org/news/sortie-de-slackware%C2%A01337 the narrow no-break spaces are rendered as dark grey squares. They appear especially just before the semicolons in the change list in the lower part of the article (starting with "noyau Linux 2.6.37.6 (2.6.38.4 dans « /testing ») ;") Reproducible: Always Steps to Reproduce: 1. Go to https://linuxfr.org/news/sortie-de-slackware%C2%A01337 Actual Results: Dark gray squares appear through the page. Expected Results: There should be narrow spaces instead. I'm with an unrooted Android 2.3.3 on a Nexus S. I guess the font used by the site doesn't contain that character, but I'd probably be unable to change it without rooting the system. Note that the base system browser (included by default) renders those characters slightly differently but still incorrectly as a white rectangle with a black border.

(In reply to comment #0) > I guess the font used by the site doesn't contain that character The problem here is that your device does not provide a font that supports this character (not just "the font used by the site", as Fennec will fall back to another font if necessary to find it), so it gets displayed as a "missing glyph" symbol instead. A possible solution could be to bundle a font with the browser that supports a wide range of Unicode characters, to be used as a last-fallback in preference to "missing glyph" boxes. (See also bug 619521.) Another possible solution for the various Unicode space characters (mostly in the U+200x column, plus U+202F) would be to "fake" them if they're missing from the current font: we could replace them with regular space glyphs, and override the width to something more appropriate. This would be bug 33032. Ideally, I think we should pursue both those issues, as they both have wider value than just this example. Marking this bug as dependent on both for now, although fixing _either_ one of them will resolve this problem.

And just to confirm, I see the same issue on an HTC Desire HD, for the same reason - lack of adequate font coverage.

This should be fixed by the patch for bug 33032 that just landed.

Verified fixed on build: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110504 Firefox/6.0a1 Fennec/6.0a1 Device: LG Optimus 2X