Closed Bug 527980 Opened 10 years ago Closed 10 years ago

Square characters in menus and tab titles

Categories

(Core :: Graphics, defect, trivial)

1.9.2 Branch
x86_64
Linux
defect
Not set
trivial

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta5-fixed

People

(Reporter: pyther, Assigned: karlt)

References

Details

(Keywords: regression)

Attachments

(5 files, 2 obsolete files)

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
Version: unspecified → 3.6 Branch
This issues seems to eventually disappear after using the browser for a little bit, but will reappear on start up.
The square characters are also seen in the bottom bar, that shows what is being loaded.
Summary: Square characters in menu's and tab titles → Square characters in menus and tab titles
I can confirm it!
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.
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?
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
Flags: blocking-firefox3.6?
--> Core::Graphics

Not able to block on 64 bit issues, as it's not a supported platform.
Component: General → Graphics
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: general → thebes
Version: 3.6 Branch → 1.9.2 Branch
(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.
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.
Flags: blocking1.9.2?
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.
Whiteboard: [should not block]
Attached file My mozconfig
Thanks Kim. Can you try rebuilding without --enable-system-cairo and retest this?
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.
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.
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.
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
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.
Blocks: 505284
Keywords: regression
Whiteboard: [should not block]
Assignee: nobody → karlt
This reproduces the same logic as for CAIRO_HAS_FC_FONT in configure.in, except that it does not depend on MOZ_TREE_CAIRO.
Attachment #414546 - Flags: review?(jmuizelaar)
I compiled with the patch and as far as I can tell the issue has disappeared.
(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.
Attachment #414546 - Attachment is obsolete: true
Attachment #414546 - Flags: review?(jmuizelaar)
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.
s/CFLAGS/CPPFLAGS/ typo.
Attachment #414582 - Attachment is obsolete: true
Attachment #414592 - Flags: review?(benjamin)
Attachment #414582 - Flags: review?(benjamin)
Attachment #414592 - Flags: review?(benjamin) → review+
The bug has disappeared with the latest patch. Thanks! :)
Flags: blocking1.9.2? → blocking1.9.2+
http://hg.mozilla.org/mozilla-central/rev/56d3b5d9c302
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs 192 landing]
Target Milestone: --- → mozilla1.9.3a1
Depends on: 532112
This broke configure on Darwin.  Filed bug 532112 with a fix.
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.)
I think I'm just hitting bug 532112, but my comment stands.
You need to log in before you can comment on or make changes to this bug.