Closed Bug 22058 Opened 25 years ago Closed 14 years ago

Mozilla practically unusable and ugly when low on colors

Categories

(SeaMonkey :: Themes, defect)

Product:
SeaMonkey
Component:
Themes
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: vroonhof, Unassigned)

References

Details

(Keywords: arch, helpwanted, relnote, Whiteboard: relnote-user)

Attachments

(8 files)

Part of the toolbar from M13 while entering an URL
939 bytes, image/gif
Details
JPEG image of mozilla.org (note icky colors)
170.63 KB, image/jpeg
Details
Comparison JPEG image of Netscape 4.72 on same system, same page
151.03 KB, image/jpeg
Details
UI still ugly when extremely low on colors (2000-04-10-08)
6.88 KB, image/gif
Details
Screenshot of Mozilla Build 2000041311 under i386 Linux
24.05 KB, image/gif
Details
Classic skin screenshot, 256 colors, PC/Linux 2000071008
7.07 KB, image/gif
Details
Mozilla on Sun Ultra 5/10 without and with enough colours, +backgound XV
26.63 KB, image/gif
Details
snapshot of mozilla121 under aix 4.3.3, IBM netstation remote terminal (8bit)
36.17 KB, image/png
Details 
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
Assignee: shuang → mcafee
Reassigning to Chris for evaluation...
Assignee: mcafee → pnunn
pam, do we have a low-color story for mozilla?
Status: NEW → ASSIGNED
This sounds more like some of the bugs Syd has
described. I'll look into it. cc'ing syd & pav
Severity: normal → enhancement
Target Milestone: M20
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.
Note, many Solaris machines are 8-bit machines.
Target Milestone: M20 → M14
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
have not been contacted by X people who
have example of ugly,unusable screens. 
Pushing out to m16. 
-p
Target Milestone: M14 → M16
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.
Severity: enhancement → normal
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Blocks: 28883
One possibility is to offer a special low color skin to make it work even on 1-
bit displays.

We actually do work on 1bit displays, and we are pretty damn useable.  Unix's
gdkrgb dithering code rocks!
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!


Marking it fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
It looks a lot better --- there's just the issue with the Toolbar, as noted by
vroonhof@math.ethz.ch (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!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The attachment is from 02-09-00. Is this still a problem?
-P
Yes --- I checked (thanks to Pavlov who rescued my Linux system ;) on this 
morning's build.

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
Thanks, Pam. (Sorry for delay.)

Marking Resolved...
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
...and Verified.
Status: RESOLVED → VERIFIED
[Split out side-issue into 34924. Thanks to vroonhof@math.ethz.ch for the screen 
snapshot!]

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
No longer blocks: 28883
beland@mit.edu, 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.

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

afranke@ags.uni-sb.de, 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!
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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...
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.

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.
Target Milestone: M16 → M17
Moving to m18
Target Milestone: M17 → M18
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.
Keywords: nsbeta3
eli can we get some qa help here? If this can be reproduced still then we 
will make it for nsbeta3.
Keywords: qawanted
This still happens with 2000072408. If you don't see this, follow the steps in
my Comments 2000-04-11 15:00.
[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!

nsbeta3-
Whiteboard: [nsbeta3-]
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...
Keywords: relnote
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.)
Target Milestone: M18 → Future
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
Blocks: 61530
QA Contact: elig → mpt
Andreas, can you be QA for this bug? I don't have an X machine to test on.
QA Contact: mpt → afranke
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.
Blocks: 66964
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.

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...
Keywords: qawanted
QA Contact: afranke → zach
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: REOPENED → NEW
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......

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...
Keywords: nsbeta3
Why not merge this bug with bug 22337 ? It looks like the same problem.
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.
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.
Blocks: 79119, qt
Keywords: arch, helpwanted
Whiteboard: [nsbeta3-] relnote-user → relnote-user
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 <hakanson@cse.ogi.edu>
CSE Computing Facilities

First of all, this should possibly be nsenterprise. 2nd, this is not UID. 
Trying themes, qa to pmac, keeping owner at pav.
Component: User Interface Design → Themes
QA Contact: zach → pmac
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.
*** Bug 105158 has been marked as a duplicate of this bug. ***
Depends on: 22337
Per timeless' comment, should this be an OS=all bug? Perhaps that would boost
the visibility a bit...
OS: Linux → All
Hardware: Other → All
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.
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
Assignee: pavlov → nobody
QA Contact: pmac → themes
Product: Core → SeaMonkey
Priority: P3 → --
Target Milestone: Future → ---
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
Status: NEW → UNCONFIRMED
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
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
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
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
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
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
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
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: