22058 - Mozilla practically unusable and ugly when low on colors

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, defect)

Description

[vroonhof]

When I use Mozilla with its window on a remote Solaris Openwin display
that only has a 256 color visual, Mozilla develops some displaying problems

Some of these make the browser practically unusable

1. The text-cursor and the highlight-for-select are not shown.
2. Chrome with the back buttons and the Location bar get black and/or garbage
backgrounds after a while.

Nightly 1999121608 running on Linux, displaying on Solaris 2.5.1. Openwin X display

Comment 1

[Eli Goldberg]

Reassigning to Chris for evaluation...

Comment 2

[Chris McAfee]

pam, do we have a low-color story for mozilla?

Comment 3

[pnunn]

This sounds more like some of the bugs Syd has
described. I'll look into it. cc'ing syd & pav

Comment 4

[Stuart Parmenter]

this needs to be fixed sooner than later.  This isn't an enhancement.  This is a
critical bug that needs to be fixed before we ship.  Mozilla looks like total
crap on anything less than a 16bit display.

Comment 5

[Chris McAfee]

Note, many Solaris machines are 8-bit machines.

Comment 6

[pnunn]

ok. I await an X chrome viewing
opportunity (when mcafee or pav
see the uglies again and give me a yell.)
Putting in m14, with the idea we might
need to push it out to m16.

-pn

Comment 7

[pnunn]

have not been contacted by X people who
have example of ugly,unusable screens. 
Pushing out to m16. 
-p

Comment 8

[vroonhof]

Attachment: Part of the toolbar from M13 while entering an URL

Comment 9

[vroonhof]

I attached a partial screen shot of the problem. Note the missing cursor.

In M13 the rendering has improved. The icons no longer turn into garbage after 
a while. They still are rendered with ugly lines.

HOWEVER. That is not main the problem. The problem is that Mozilla is not
showing any cursor. In the same way it does not show any highlighting.
For this reason I upgraded the Severity. Without a cursor editing text becomes a
pain. Sorry if upgrading the severity is "not done". 


Note that in some previous snapshot I managed to convice Mozilla to use a
private color map (needed to browse the source to find out to that). However
upgrading to M13 ahs whiped out my prefs.js file and cannot seem to find the
magic 
to do that any more. However once the color map thing works, Mozilla starts
showing a cursor.

Comment 10

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 11

[german]

One possibility is to offer a special low color skin to make it work even on 1-
bit displays.

Comment 12

[Stuart Parmenter]

We actually do work on 1bit displays, and we are pretty damn useable.  Unix's
gdkrgb dithering code rocks!

Comment 13

[vroonhof]

Yipee!

I just tried build 2000031416 and there has been a marked improvement. 
The skin has turned green, but finally the cursor is visible!

The select highlighting is visible too. Unfortunately when selecting black text
on a white background it uses a dark green for the foreground which doesn't
contrast very well wit the grey it uses for the foreground. On other color
combinations it works fine.

Whoever fixed this, thanks!

Comment 14

[neeti]

Marking it fixed

Comment 15

[Eli Goldberg]

It looks a lot better --- there's just the issue with the Toolbar, as noted by
[e-mail] (along with the great screen shot.)

I'm re-opening this. Pam, please let me know if the Toolbar issue should be
split off into a separate bug report (with this one closed out), or what you'd
like. Thanks!

Comment 16

[pnunn]

The attachment is from 02-09-00. Is this still a problem?
-P

Comment 17

[Eli Goldberg]

Yes --- I checked (thanks to Pavlov who rescued my Linux system ;) on this 
morning's build.

Comment 18

[pnunn]

Eli:

It makes sense to isolate the toolbar problem in a separate
bug. Let's close this guy out and open a new one on the toolbar.

-p

Comment 19

[Eli Goldberg]

Thanks, Pam. (Sorry for delay.)

Marking Resolved...

Comment 20

[Eli Goldberg]

...and Verified.

Comment 21

[Eli Goldberg]

[Split out side-issue into 34924. Thanks to [e-mail] for the screen 
snapshot!]

Comment 22

[Christopher Beland]

Attachment: JPEG image of mozilla.org (note icky colors)

Comment 23

[Christopher Beland]

Attachment: Comparison JPEG image of Netscape 4.72 on same system, same page

Comment 24

[Christopher Beland]

Having downloaded the "Netscape 6" preview release, I confirmed that there are
still a lot of color problems on my system (which is low on colors, but what can
you do?).  Mozilla is usable, but pretty darn ugly and messy.  (So much so I'm
sticking with Netscape 4 for now...)  I've included screenshots of the browser,
and Netscape 4.72 - which I think makes a fair benchmark for minimum performance
- on my system for comparison.  (The JPEGs are a bit grainy, but you can clearly
see the difference.)

Thanks for all the great work on this project!

Beland

Version: Mozilla/5.0 (X11; N; Linux 2.2.12-20 i686; en-US; m14) Netscape6/6.0b1
BUILD ID: 2000032406

Comment 25

[Eli Goldberg]

[e-mail], Netscape 6 PR1 ~= Mozilla from a month or two ago, before this 
bug was fixed. 

I'd be happy to re-open this if you have a screenshot from a current *Mozilla* 
build.

Comment 26

[Andreas Franke (gone)]

Attachment: UI still ugly when extremely low on colors (2000-04-10-08)

Comment 27

[Eli Goldberg]

Hrf...I can't reproduce that, but re-opening.

[e-mail], you did restart the application after changing bit depth, 
right? (there's another bug in which it messes up the chrome if you change bit 
depth while it's running.) Thanks!

Comment 28

[Andreas Franke (gone)]

I don't know if (or how) I could change the bit depth of my
display if I wanted to. I'm quite sure I always have 8 bit.
Note: mozilla is running on a remote machine.
I'll try to find out the exact conditions when this happens...

Comment 29

[Andreas Franke (gone)]

I found a way to reproduce this consistently:
- Log in on the local machine, startx (8 bit)
- Log in on the remote machine with an up-to-date linux,
  and do the following there (in this order):
  > xv &         (shows title: xv 3.10a(PNG) ...)
  > netscape &   (Communicator 4.61)
  > mozilla
- See the screwed-up colors of mozilla.

added myself to cc.

Comment 30

[Christopher Beland]

Attachment: Screenshot of Mozilla Build 2000041311 under i386 Linux

Comment 31

[Christopher Beland]

The above attachment shows what I get right when Mozilla starts up, after a
fresh install.  I even killed other color-intensive applications.  I get
basically the same effect as the 4/11 attachment shows.  From the output of
xdpyinfo, it looks like I have max 256 colormap entries available, just like the
original reporter.

Comment 32

[neeti]

Moving to m18

Comment 33

[Andreas Franke (gone)]

Nominating for nsbeta3 because I'm suffering from this a lot.
Classic skin is completely unusable with this (e.g. scrollbars are invisible).
I'm getting this problem whenever I run mozilla with netscape already running.

Comment 34

[Andreas Franke (gone)]

Attachment: Classic skin screenshot, 256 colors, PC/Linux 2000071008

Comment 35

[Gagan]

eli can we get some qa help here? If this can be reproduced still then we 
will make it for nsbeta3. 

Comment 36

[Andreas Franke (gone)]

This still happens with 2000072408. If you don't see this, follow the steps in
my Comments 2000-04-11 15:00.

Comment 37

[Eli Goldberg]

[Gagan --- guessing Andreas counts as excellent QA help based on his comments. if 
there's anything I can do for you personally, just say so.]

Thanks, Andreas!

Comment 38

[Gagan]

nsbeta3-

Comment 39

[Andreas Franke (gone)]

So will someone update the release notes for netscape6 and mozilla to state that
on Linux it is required to have a 16bit display? IMHO that would be the simplest
solution...

Comment 40

[Hallvard B Furuseth]

Attachment: Mozilla on Sun Ultra 5/10 without and with enough colours, +backgound XV

Comment 41

[Hallvard B Furuseth]

If you think the previous examples are bad, take a look at
<URL:http://www.uio.no/~hbf/m.gif> form a Sun Ultra 5/10.
It shows one mozilla without enough colours (because Netscape had
grabbed most available colours), one with enough colours, and
XV in the background.  XV was also started while Netscape had
grabbed the colours, which shows that you can have nice colours
anyway.  (It's in 8-bit mode; it looks less nice in 24-bit mode).
A 2nd netscape also has readable images and colours even though
it can't get enough colours; it just looks more boring.

(Sorry about the separate URL; I tried to make an attachment but
it was munged.)

Comment 42

[Matthew T (active 1999-2002)]

Andreas, can you be QA for this bug? I don't have an X machine to test on.

Comment 43

[Andreas Franke (gone)]

Well, maybe, as long as our last 8bit display machine is not upgraded. I'm not
root here. I would be happier if someone else could do this.
beland, Hallvard: if you want to be QA contact here, please take it.

Comment 44

[Keyser Sose]

The reporter on bug 65881 commented on how to modify the colormap preferences 
so that it uses the installed colormap:

From bug 65881:
I don't have a diff handy, but the change is trivial.  In
widget/src/gtk/nsAppShell.cpp, there is a function HandleColormapPrefs().  
Add

gdk_rgb_set_install( TRUE );
return;

at the top of the function.

The same effect can be had by changing modules/libpref/src/unix/unix.js
so that 
pref("browser.installcmap", true);

instead of the default false value.

Comment 45

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 46

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 47

[Gregg C]

I have many ultrasparc machines, all with 8 bit displays, none of the default
skins, nor any at x.themes.org will render properly on an 8 bit display. As I
type this I can hardly even tell where the scrollbars, buttons, and text boxex,
etc begin or end. Except for the icons which have sucked all but 2 or 3 of my
colors,all the widgets are rendered in either black or white. With the
foreground, background, and most of the shadow details all rendered in white.
Dont even ask how the websites look. At this point in 8 bits of color, **lynx**
handles graphics better than mozilla.

In terms of crashing, etc mozilla is doing extremely well, I use it on my home
machines all the time now, but this color thing......

Comment 48

[Andreas Franke (gone)]

Gregg, since you can easily reproduce this problem, feel free to install
yourself as QA contact for this bug. Some time ago, we had 8bit displays here,
but they have gone away, so I can't help with this anymore...

Comment 49

[Reinout van Schouwen]

Why not merge this bug with bug 22337 ? It looks like the same problem.

Comment 50

[Andreas Franke (gone)]

As I understand it, bug 22337 is about adding a private colormap for Mozilla in
case of 8-bit displays. That may solve this problem, but that doesn't mean that
it's the only solution. I'm no expert in this area, but I think it could be
possible to somehow gracefully degrade and use very few colors if there aren't
enough colors available, without producing ugly garbage on the screen.
Someone with a better understanding of imglib on linux may be able to give an
overview about the possible approaches here.

Comment 51

[Gregg C]

A 2 or 3 color skin would help alot, an 8 bit display only has so many colors,
especially if mozilla is not the only app running, the display will look bad. I
personally don't like using seperate colormaps, but the option is good to have,
because in some circumstances that is the only thing practical. But even if the
webpages look bad because of few colors, then at *least* the netscape widgets,
forms and other graphical features should be visable and usable. That part
should be free of "weird colors" and garbage.

I could work on such a low color skin now, but I have not been able to find
anykind of howto to make them. If someone would point me in the right direction,
I could try, also a low color animated mozilla icon would help. I just want the
application to look simple, clean, and not flash when changing focus. It just
looks more professional that way. Except for the limited colors, the systems we
have are very usable systems. Now, these machines are outdated in pure CPU
power, but they are very stable with quality construction, some individual
machines have upwards of a year or 2 of uptime under solaris. If I can get these
running linux + mozilla then these boxes can serve their purpose for the next
decade or so.

Comment 52

[Andreas Franke (gone)]

Theme Builder Tool: http://chameleon.mozdev.org/
Existing Themes:    http://x.themes.org/viewresources.phtml?type=chrome

Comment 53

[Marion Hakanson]

Folks,

I just want to comment here that this is a pretty serious problem for our site,
since we have more than 100 X-terminals with 8-bit displays.  We mostly connect
them to Sun/SPARC/Solaris and Intel/Linux servers.

Old netscape-4.7x has a feature where you can tell it to use fewer than all
the available colors (by changing an X resource).  We find decent results
(not great, but useable) with as few as 120 colors.  And for better results,
we can use the "-install" option if we want to put up with colormap flashing.
I've not yet found similar options in netscape-6 (6.01a, from Sun).

Some of the open-source image display programs, like "xv" and "ImageMagick"
work quite well using a standard colormap (xstdcmap(1)) and give even better
results than netscape does (more available cells if you can share them!).
Why doesn't netscape-6 do something similar?

I've run across information which makes it look like gdk (upon which
mozilla/netscape-6 is based) supports extensive colormap handling,
including good dithering for 8-bit displays:

 http://www.gtk.org/~otaylor/whitepapers/color-handling.html
 http://www.geocrawler.com/mail/thread.php3?subject=256+Color+Dithering&list=11
2

So why doesn't netscape-6 make use of these facilities?

And even if nobody is going to make use of these approaches, telling users
that they're out of luck, or they have to buy new hardware, is not going to
convince them to use your software.  How about putting out some info similar
to that available for netscape-4.x, suggesting how to make the most of
an 8-bit display's colors?

Regards,

-- 
Marion Hakanson <[e-mail]>
CSE Computing Facilities

Comment 54

[Zach Lipton [:zach]]

First of all, this should possibly be nsenterprise. 2nd, this is not UID. 
Trying themes, qa to pmac, keeping owner at pav.

Comment 55

[timeless]

ooh. i was hoping this bug would turn up. i ran into this on a 4bit w98 
computer. there were only two web browsers installed ns6.1 and ie5.5. ie was 
thoroughly broken (crashing constantly -- and killing the os...), so we needed 
to use mozilla to do things like get a video driver and other stuff while we 
rebuilt the basics. as usual, switching to classic helped a bit, although not 
much.

-- yes the display could run in truecolor, but we couldn't do that until after 
we found and installed a correct driver, so we were effectively running in an 
unsafe safe mode :o, 640x480x16colors.

Comment 56

[Stuart Parmenter]

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

Comment 57

[Reinout van Schouwen]

Per timeless' comment, should this be an OS=all bug? Perhaps that would boost
the visibility a bit...

Comment 58

[Yakov Mindelis]

Attachment: snapshot of mozilla121 under aix 4.3.3, IBM netstation remote terminal (8bit)

On IBM netstations (8bit) used as remote terminal with AIX4.3.3, mozilla1.2.1
has distorted colormap (ecpecially menus+buttons bg color, URL field, status
bar). mozilla1.1 doesn't have the problem, both use install colormap. tested
when no other color-hungry X-applications were running.

Comment 59

[Thomas Schein]

try changing your display on yor computer 

   Go to your control panel
    Click on display
     go to the setting tab at the top of the windows that oped up
      at the bottom of the screen there is a menu that says how many colors your
are using change it the 32-bit if you have it if not try a differant display driver
 

Comment 60

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 61

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 62

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 63

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 64

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 65

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 66

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 67

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420