187335 - missing (disappearing) lines with gtk2 xft build if the character coding is wrongly set

Status: RESOLVED DUPLICATE of bug 182650

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

Description

[Iñaki Garcia Etxebarria]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021225
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021225

When showing pages with characters in the wrong character set (say, displaying a
ISO-8859-1 page and telling mozilla it's UTF-8) the whole line were the
character is  disappears.
The funny thing is that it's still possible to select the text in the line and,
when highlighted, the text shows up correctly, except the offending characters.
As soon as you dehighlight the line disappears again.

Reproducible: Always

Steps to Reproduce:
1. Start a gtk2 xft build (possibly others)
2. Open the page i link to (there are many others)
3. Set the character encoding to UTF-8
Actual Results:  
The lines of text containing the offending characters do no display.

Expected Results:  
Display some sort of "character cannot be decoded" sign (a '?' for example, as
"normal" moz 1.2 does) for the badly encoded chars and render the rest of the
line correctly.

Arguments passed to ./configure:
--enable-default-toolkit=gtk2 --disable-gtktest --disable-mailnews
--disable-ldap --disable-freetypetest --enable-xft --disable-postscript
--disable-xprint --enable-crypto --disable-jsd --enable-xinerama
--disable-composer --disable-mathml --disable-installer --disable-tests
--disable-debug --enable-optimize=-O2 --disable-dtd-debug --disable-pedantic
--disable-glibtest

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->blizzard.  I don't see the problem in a non-GTK2 Xft build or in a regular build.

Comment 2

[Jimmy Yen]

It happens to me too, but only with certain fonts (fonts that don't have the
characters needed, IIRC.)

Comment 3

[Ari Pollak]

I'm seeing this in 1.3b with gtk2/xft. Attaching screenshots of page set in
UTF-8, and in standard Western ISO-8859-1.

Comment 4

[Anthony Fok]

(Note: This is a duplicate of Bug 187377 and a few others.  Search for the
string "Xft"...)

This is not a Mozilla bug, but rather, a XFree86/libXrender one, which has been
fixed in XFree86 CVS (post 4.2.1) some months ago.  Owen Taylor and Mike Harris
included this fix in Red Hat 8.0:

* Sun Sep 01 2002 Mike A. Harris <[e-mail]> 4.2.0-70
- Updated custom startup log patch to fix a few glitches
- Added -fPIC to x86_64 compiler flags until better solution is made in future
- Added XFree86-4.2.0-libXrender-bugfix.patch to fix showstopper (#73243)

See  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73243

Thanks to Keith Packard for pointing me into the right direction.

AFAIK, neither Debian (the latest unstable/sid) nor FreeBSD has picked up this
patch yet.  I added the patch to my Debian (sid) machine (built locally as
XFree86-4.2.1-5.1), and it works for me.  :-)  Please try it out and see if it
fixes your problem too.

Cheers,

Anthony

Comment 5

[Iñaki Garcia Etxebarria]

Upgrading to CVS XFree86 fixes it for me, yes. Thanks for the tip.

Comment 6

[Christopher Blizzard (:blizzard)]

Marking as invalid based on reporter's comments.

Comment 7

[Iñaki Garcia Etxebarria]

Nah, spoke too fast, sorry. The bug is still there, so we can rule out the
suggested fix.
But I can see the correct page from time to time (that's why i thought it
worked), will try to find some pattern...

Comment 8

[Frederic Crozat]

This looks like a duplicate of bug 182650.. 

Comment 9

[Iñaki Garcia Etxebarria]

It turns out that my local installation of X was a bit screwed, a clean one does
indeed fix the bug.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** This bug has been marked as a duplicate of 182650 ***

Comment 11

[Asa Dotzler [:asa]]

*** Bug 189817 has been marked as a duplicate of this bug. ***