Closed
Bug 22058
Opened 25 years ago
Closed 15 years ago
Mozilla practically unusable and ugly when low on colors
Categories
(SeaMonkey :: Themes, defect)
SeaMonkey
Themes
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: vroonhof, Unassigned)
References
Details
(Keywords: arch, helpwanted, relnote, Whiteboard: relnote-user)
Attachments
(8 files)
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
Updated•25 years ago
|
Assignee: shuang → mcafee
Updated•25 years ago
|
Assignee: mcafee → pnunn
This sounds more like some of the bugs Syd has described. I'll look into it. cc'ing syd & pav
Comment 4•25 years ago
|
||
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.
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
Comment 10•25 years ago
|
||
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
Comment 11•25 years ago
|
||
One possibility is to offer a special low color skin to make it work even on 1- bit displays.
Comment 12•25 years ago
|
||
We actually do work on 1bit displays, and we are pretty damn useable. Unix's gdkrgb dithering code rocks!
Reporter | ||
Comment 13•25 years ago
|
||
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•25 years ago
|
||
Marking it fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 15•25 years ago
|
||
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 → ---
Comment 17•25 years ago
|
||
Yes --- I checked (thanks to Pavlov who rescued my Linux system ;) on this morning's build.
Comment 18•25 years ago
|
||
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•25 years ago
|
||
Thanks, Pam. (Sorry for delay.) Marking Resolved...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 21•25 years ago
|
||
[Split out side-issue into 34924. Thanks to vroonhof@math.ethz.ch for the screen snapshot!]
Comment 22•25 years ago
|
||
Comment 23•25 years ago
|
||
Comment 24•25 years ago
|
||
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
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
Comment 27•25 years ago
|
||
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 → ---
Comment 28•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
Comment 31•25 years ago
|
||
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 33•25 years ago
|
||
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
Comment 34•25 years ago
|
||
Comment 35•25 years ago
|
||
eli can we get some qa help here? If this can be reproduced still then we will make it for nsbeta3.
Keywords: qawanted
Comment 36•25 years ago
|
||
This still happens with 2000072408. If you don't see this, follow the steps in my Comments 2000-04-11 15:00.
Comment 37•24 years ago
|
||
[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 39•24 years ago
|
||
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•24 years ago
|
||
Comment 41•24 years ago
|
||
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.)
Updated•24 years ago
|
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
Updated•24 years ago
|
QA Contact: elig → mpt
Comment 42•24 years ago
|
||
Andreas, can you be QA for this bug? I don't have an X machine to test on.
QA Contact: mpt → afranke
Comment 43•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
Comment 46•24 years ago
|
||
All pnunn bugs reassigned to Pav, who is taking over the imglib.
Assignee: pnunn → pavlov
Status: REOPENED → NEW
Comment 47•24 years ago
|
||
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•24 years ago
|
||
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 50•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Theme Builder Tool: http://chameleon.mozdev.org/ Existing Themes: http://x.themes.org/viewresources.phtml?type=chrome
Comment 53•23 years ago
|
||
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
Comment 54•23 years ago
|
||
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
Comment 55•23 years ago
|
||
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 57•23 years ago
|
||
Per timeless' comment, should this be an OS=all bug? Perhaps that would boost the visibility a bit...
Comment 58•22 years ago
|
||
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•21 years ago
|
||
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
Updated•18 years ago
|
Assignee: pavlov → nobody
QA Contact: pmac → themes
Assignee | ||
Updated•16 years ago
|
Product: Core → SeaMonkey
Updated•16 years ago
|
Priority: P3 → --
Target Milestone: Future → ---
![]() |
||
Comment 60•16 years ago
|
||
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
![]() |
||
Comment 61•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•15 years ago
|
||
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: 25 years ago → 15 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•