251142 - Coloured text appearing black

Status: RESOLVED WORKSFORME

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

Description

[Shalom Naumann]

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

I have used http://www.gamedev.net/ many times, including on Mozilla, with no
problems. However, I recently reinstalled linux (I wanted to try Gentoo) and
when I reinstalled Mozilla 1.6, large blotches of text on http://www.gamedev.net
and its subpages, which use the same CSS, appear in black, making it very hard
to see. Usually refreshing helps or changes it to a different black splotch.
Scrolling away and coming back always works. Often as its loading parts will
alternate between black and the proper colour. It does not appear to happen any
where else, but I haven't tested extensively.

Reproducible: Sometimes
Steps to Reproduce:
1. Open http://www.gamedev.net or any of its subfolders.
Actual Results:  
Parts of the text were black.

Expected Results:  
Use the website's colours as defined by CSS.

I am using XOrg.
The following is the output of emerge info on my computer:
Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0,
2.6.5-gentoo)
=================================================================
System uname: 2.6.5-gentoo i686 Intel(R) Pentium(R) 4 CPU 1300MHz
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium4 -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
http://gentoo.mirrors.pair.com/ http://mirror.datapipe.net/gentoo
http://mirrors.tds.net/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X alsa apm arts avi berkdb bidi bindist crypt cups directfb emacs encode
fbcon foomaticdb ftp gdbm gif gpm gtk gtk2 icc imlib java jikes jpeg kde libg++
libwww mad mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam
pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcpd tidy
truetype usb wxwindows x86 xml2 xmms xv zlib"

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a problem with a mozilla.org build?  Or just the gentoo builds?

Comment 2

[Shalom Naumann]

My guess is that its a problem with Mozilla itself, because the Gentoo "builds"
are basically just the source code with some compilation information added on. I
compiled it with -O3, though I have compiled Mozilla with -O3 before without any
problems (in LinuxFromScratch with XFree 4.3).

Comment 3

[Shalom Naumann]

Attachment: A screenshot

I just realised that I never posted the screenshot I made.

Comment 4

[Shalom Naumann]

I just realised that I am seeing the same problem on a different website - on no
less thhan http://packages.gentoo.org. The backage list on the left sides often
appears partially black, as well as the well as the individual package names in
the main content pane. Everything else on the page, though, is appearing in the
correct colour.

Comment 5

[Shalom Naumann]

I think it must have to do with XOrg, because I just fiddled around with the
settings in xorg.conf and the problem seems to have disappeared. The only
settings that I changed were - 1) explicitly setting a ModeLine instead of using
one of the VGA defaults 2) removing some strange Display SubSections put in by
xorgcfg, leaving only the 24 bit one and explicitly setting the ModeLine to use
with Modes 3) Set the DefaultDepth to 24 and 4) Added support for my mouse's
scrollwheel. 
I'm pretty sure that before I was not getting a 24bpp display because I think I
saw some dithering. Perhaps that somehow made all that text black on those
pages. I'll look to see if XOrg has a bug-reporting system and reference this bug.

Comment 6

[Boris Zbarsky [:bzbarsky]]

If you were running in 8-bit color, it's quite possible that there were no more
colors to allocate and the rendering fell back to black... If that was the
problem, this bug is invalid -- that's just the way limited color-spaces work.

Comment 7

[Roland Mainz]

Boris Zbarsky wrote:
> that's just the way limited color-spaces work.

That's the way how the very limited non-TrueColor visual support in GTK+
applications work. Normally - like old NS4.x does - the application may reuse
existing color map entries and assign a new color to it (if this matches the
fits better).
GTK+ applications only have a static palette and can't do more... ;-(

Comment 8

[Shalom Naumann]

I'm sure it was more than a simple lack of available colours. It kept switching
between black and the correct colour, often switching as the page was loading
and usually some parts in black with others in the correct colour. Additionally,
I don't think that I was "using up" an entire pallette's worth of colours - this
problem occurred even if I just opened up X with a really simple window manager
(Ion) and went straight to the website. And most webpages use "web-safe" colours.

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[Andrei Purice]

Marking this as Resolved > Worksforme since the issue no longer is reproducible on the latest versions of Firefox Nightly 95.0a1 (2021-10-14), beta 94.0b6 or release 93.0 on Ubuntu 20.04.
If anyone can still reproduce the issue either re-open it or file a new one.