527980 - Square characters in menus and tab titles

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Pyther]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b2) Gecko/20091111 Firefox/3.6b2
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b2) Gecko/20091111 Firefox/3.6b2

Square characters are displayed for some menu items and some page titles. This did not happen with Firefox 3.6b1.

I will add some screenshots to show exactly what is happening. 

A few users report the same issue here: http://aur.archlinux.org/packages.php?ID=22919

Reproducible: Always

Comment 1

[Pyther]

This issues seems to eventually disappear after using the browser for a little bit, but will reappear on start up.

Comment 2

[Pyther]

Attachment: Screenshot of the issue at hand

Comment 3

[Pyther]

Attachment: A unicode symbol next to Browse

The square characters are also seen in the bottom bar, that shows what is being loaded.

Comment 4

[Kalpik Nigam]

I can confirm it!

Comment 5

[Devin Cofer]

Also confirmed.

No matter how I build Firefox, I get the problem.  Sometimes Firefox with start without the symbols, but once I restart it, they're back.
Also, sometimes they will just go away mid-run.
It is very odd.

Comment 6

[Devin Cofer]

Screenshot of issue for me: http://omploader.org/vMnI2cg

All the squares seem to say 20 over 26?  Is that a Unicode/UTF-8 thing?

Comment 7

[Micah Gersten]

This happens with the 64 bit version I built for Ubuntu, but not with the i686 version from Mozilla.  I see this on the select profile screen, so I know it's not a profile issue.  I'm attaching a screenshot of that.  Are there any 64 bit Mozilla builds I can test?

My PPA in case anyone wants to examine the build logs or try the packages:
https://launchpad.net/~micahg/+archive/mozilla-beta/+packages

Comment 8

[Micah Gersten]

Attachment: Screenshot of Profile selector with Unicode issue

Comment 9

[Kim Silkebækken]

Confirmed on Arch Linux 64-bit. Creating a new profile doesn't work. The unicode fallback glyphs appear both in the UI and on some web sites (e.g. on russ.no, a norwegian site using the font "Lucida Grande"). The bug seems to disappear when using certain fonts, e.g. "DejaVu Sans" and "Droid Sans Fallback" (but not "Droid Sans").

Some international characters doesn't get swapped with unicode fallback glyphs, but with other characters. Norwegian characters "æ" and "ø" gets swapped with "Ȇ" and "‾".

I think this bug may have been introduced in mozilla-central rev 34428: http://hg.mozilla.org/mozilla-central/rev/94f9e903f285. I've tried backing out this changeset and the bug disappeared. I haven't been able to backout the changeset lately without getting build errors.

I also think the bug may be related to Pango font rendering, as building Firefox without Pango works fine (but results in ugly antialiasing).

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Core::Graphics

Not able to block on 64 bit issues, as it's not a supported platform.

Comment 11

[benisty.e]

(In reply to comment #10)
> --> Core::Graphics
> 
> Not able to block on 64 bit issues, as it's not a supported platform.

FTR, same issue on i686 here.

Comment 12

[Pyther]

I also have the same issue on a i686 build. If you would like I could post a screenshot of the issue on the i686 build.

My i686 machine and x86_64 machine run the same software versions.

Comment 13

[Joe Drew (not getting mail)]

Has anybody been able to reproduce this with a Mozilla.org build? Maybe this is a system cairo vs in-tree cairo problem? Can someone who's built Firefox and sees this problem post their .mozconfig?

Until we get confirmation that this is happening on our builds, I recommend we not block on this.

Comment 14

[Kim Silkebækken]

Attachment: My mozconfig

Comment 15

[Joe Drew (not getting mail)]

Thanks Kim. Can you try rebuilding without --enable-system-cairo and retest this?

Comment 16

[Kim Silkebækken]

I just built Firefox without --enable-system-cairo. I can confirm that the bug is gone as far I can see, but the font antialiasing looks bad. My installed cairo packages are:

% pacman -Qs cairo
local/cairo-ubuntu 1.8.8-1
    Cairo vector graphics library, with Ubuntu's LCD rendering patches
local/cairomm 1.8.2-1
    C++ bindings to Cairo vector graphics library
local/lib32-cairo 1.8.8-1 (lib32)
    Cairo vector graphics library
local/pycairo 1.8.6-1
    Python bindings for the cairo graphics library

I've tried Arch Linux' regular cairo package without Ubuntu's font rendering patches as well (version 1.8.8) but the bug still occurs in all my builds with system cairo enabled.

Comment 17

[Joe Drew (not getting mail)]

OK. We're probably depending on some fixes in our version of Cairo that isn't in the version Arch is shipping. We should work out what that is so Arch can fix the bug, but this definitely doesn't block.

Comment 18

[Kim Silkebækken]

Ok. Please note that Arch's Cairo package and the C++ bindings are unpatched versions from cairographics.org - maybe this could affect others using Cairo 1.8.8 as well. See http://repos.archlinux.org/wsvn/packages/cairo/repos/extra-x86_64/PKGBUILD for Cairo build details.

Comment 19

[Micah Gersten]

It seems like 1.9.2 got cairo patches from trunk between beta 1 and beta 2 which must have fixed this for the mozilla builds:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ebbeedee7a9a

Comment 20

[Karl Tomlinson (:karlt)]

This is a regression from bug 505284.

It was supposed to be fixed by bug 525845, but that doesn't work with system-cairo because it doesn't have CAIRO_HAS_FC_FONT set.

I think this is a regression that should block.

Comment 21

[Karl Tomlinson (:karlt)]

Attachment: don't use tree-cairo preprocessor symbols to test for fontconfig

This reproduces the same logic as for CAIRO_HAS_FC_FONT in configure.in, except that it does not depend on MOZ_TREE_CAIRO.

Comment 22

[Pyther]

I compiled with the patch and as far as I can tell the issue has disappeared.

Comment 23

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #21)
> Created an attachment (id=414546) [details]
> don't use tree-cairo preprocessor symbols to test for fontconfig
> 
> This reproduces the same logic as for CAIRO_HAS_FC_FONT in configure.in, except
> that it does not depend on MOZ_TREE_CAIRO.

Wouldn't it better if we set HAVE_FONTCONFIG from configure.in? That way, even if we do have to duplicate the test, the duplication is at least in the same place and not in two different ones.

Comment 24

[Karl Tomlinson (:karlt)]

Comment on attachment 414546 [details] [diff] [review]
don't use tree-cairo preprocessor symbols to test for fontconfig

Jeff is right.  configure is a better place to do this.  I was being lazy.

Comment 25

[Karl Tomlinson (:karlt)]

Attachment: don't use tree-cairo preprocessor symbols to test for fontconfig (use configure)

Comment 26

[Karl Tomlinson (:karlt)]

Attachment: don't use tree-cairo preprocessor symbols to test for fontconfig (use configure)

s/CFLAGS/CPPFLAGS/ typo.

Comment 27

[Kim Silkebækken]

The bug has disappeared with the latest patch. Thanks! :)

Comment 28

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/56d3b5d9c302

Comment 29

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6bd2fb22270f

Comment 30

[Hanspeter Niederstrasser]

This broke configure on Darwin.  Filed bug 532112 with a fix.

Comment 31

[(not currently active) Ted Mielczarek]

Karl: when adding configure checks like this, we're trying to nowadays add more helpful text in the error messages. In the future, it'd be great if you could include -dev package names in the error message for at least Fedora and Ubuntu, to make life easier for people.
(I just hit this trying to build an x86 build on my 64-bit system, and I can't for the life of me figure out what package I'm missing.)

Comment 32

[(not currently active) Ted Mielczarek]

I think I'm just hitting bug 532112, but my comment stands.