Maybe only a configuration issue, but I failed to get it right... The Solaris nightly build 1999-05-03-08's viewer app seems to change the whole screen's palette in 8 bit environments (most old Sparcs and cheap Ultra-5 have this 8-bit cards :-(( ), instead of choosing the nearest color from the shared pen table like Netscape 4.x does. Deactivating viewer app's window turns normal palette on (what else :-) ). Would be nice if there is a prefs-option to select between own palette and shared-palette mode. I cannot test this with apprunner because this beast throws a core dump on my hard-disk... (--> next bug report...)

apprunner does the same (the crash was a "first startup" crash as reported in bug report #5891) thing with the colors. This problem does only occur on my sparcStation 5 (70MHz), my Ultra-5 does not have the color problem (but maybe I`m wrong and Sun has accidently delivered me a Ultra-5 with a non-8 bit gfx-card :-)) ). (Any idea how to figure out the current big-depth of the screen without writing a C problem ?)

Syd -- can you please take a look?

We do not test Solaris internally. Thus making Roland.Mainz@informatik.med.uni-giessen.de the QA Contact to verify when fixed.

This is also a Linux problem -- the real issue is we grab a private colormap for 8-bit visuals (e.g., PseudoColor). And I've duplicated on my Linux laptop. I'm leaving the platform as is and we should use Roland as QA contact, but I just wanted to be clear on the issue of what platforms are really affected.

Thanks for the new job !! :-) AFAIK there's a difference between "allocate an own palette for a window" (private colormap) and "allocate a palette from available shared colors" (shared colormap) on 8-bit-visuals. The tested solaris build simply allocates it's own palette (which gets used when the user selects the window), and this looks little bit ugly. Did someone test Mozilla on a Linux-box and a 8-bit display ? There should be an option what to use: Shared colormap or private colormap... This option should be selectable in a per-window manner that high-quality JPEGs can be viewed with a "optimized" private colormap; normal pages should use the shared colormap.

Mhhh, I got a "Mid-air collision detected!" for this bug (seems that syd and I were writing responses at the same time) :-) ---- BTW: my Ultra-5 has a 24-bit visual. I never noticed this until now :-) ---- I'd like to change the Platform from "Solaris" to "All-Unix", but there was no such thing... Should I make a bugzilla-enhanchment request ?

We'll check is on Linux here for you. sujay, can you check out with last working Apprunner for Linux please?

Make sure that the default visual is 8-bit pseudocolor. If it is anything else, likely you won't see it. A convenient way to check for default visual class is to use xdpyinfo. BTW, I run 8-bit pseudocolor as my default visual on my Linux laptop, so I see it everyday.

Got a fix, finally. Reviewed by alecf, but cannot checkin because tree is in flames. Should be in for M8, changing target to that. Basically, added a preference "browser.installcmap", which is defaulted to false. In this case, we tell Gtk+ (actually Gdk) to use the default colormap. If true, a private colormap is forced. The implementation is based on a value that we can set in gtk_rgb that specifies minimum number of colors needed by a colormap. If installcmap is false, we set this to zero so any colormap will satisfy the requirement. If set to true, we use 255 which will force the install of a private colormap. Also, added "browser.ncols". If "browser.installcmap" is not specified in prefs, then this can be used to fine tune the minimum colors value used by gdk. Added ramiro to cc list.

1. Please check if this new option is a NOP on truecolor visuals (should be...) 2. What about Motif ? - I know that the Motif code is currently not working, but the option should be added to the Mozif side, too - or we should file another bug that Motif is missing/ignoring this option. -- I cannot check the bug fix yet. The last Solaris build was broken :-( Waiting for a working one...

Thanks Syd. I think you can still get it in for m7. The tree should open later today.

Fixed. Way to test: just start up on an 8-bit Pseudocolor server. The default prefs in unix.js, browser.ncols, and browser.installcmap, are set so that default colormap will be used. Effective range for ncols is 0 <= ncols <=255. ) means need at least 0 colors to used default shared cmap, 255 means need all 255. Set to value out of that range and it won't be changed (the default Gdk value of 5 * 5 * 5 will remain). Next, we check and handle installcmap. If set to true, it will set the threshold value to 255, forcing an install because no shared colormap will allow gdk to allocate that many colors. If set to false, we set threshold to 0, which can obviously be granted by any colormap.

I don't have the configuration available to test this...can one of you please verify this is fixed and mark VERIFIED_FIXED ? I'd really appreciate this very much. thanks!

I'd be glad to demo it for you if you want to drop by (I'd rather not verify my own bug).

verified in 6/18 build. Syd demo'd for me..

Sorry, I cannot check this due bug 8413 (recent Solaris builds do not work...) :-(

Now works on my Solaris 7 box. Tested with my own build (based on mozilla-source-1999-06-19-08-M7.tar.gz sources). The problem is still present if Mozilla 4.x sits in the same display (IMHO no bug, there are simply too few colors left...).

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

marking dependant on solaris-crash-on-startup bug