160405 - Browser doesn't load private colormap

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Martin Lawyer]

This bug report is to address the HPUX-only addition of the fix for bug 65881

On machines with 8-bit graphics adapters, when launching Mozilla after other
graphical applications are already running and using up available colors, the
color palette is bad.  Using the "-install" option (added for bug 22337) does
nothing. 

Fix recommended by Dan Dickerson in bug 65881 to be attached as a patch.

Comment 1

[Martin Lawyer]

Attachment: Suggested patch, HPUX only

Comment 2

[Martin Lawyer]

Attachment: Updated patch. Final version.

Comment 3

[Jim Dunn]

Why is this HP-UX only??? hmmm
Syd, what do you think about this?

Comment 4

[Martin Lawyer]

I believe the bug fix should be made for all platforms in the trunk.  However,
since the parent bug was not getting any attention for tier-1 platforms in this
release, and other OEM platforms claim that it is already working properly for
them, I felt the safest course was to make the change (in the OEM branch) HP-only.  

Comment 5

[Jim Dunn]

syd this is the bug you said you would look at the other night.
(chris I was just adding you to be thorough)

Comment 6

[Syd Logan]

Could someone clarify some things for me?

Does doing this cause other windows (and the desktop) to go hypercolor when
focus is placed inside the browser?

The statement -install means what, exactly? Is it that it totally doesn't work,
meaning a private colormap is not given (seems unlikely), or is it that the
chrome seems to not be playing with the private colormap (there was some mention
of themes looking weird).

I'd *love* to see some screenshots, please attach some gifs illustrating the
problem with some verbosity telling what steps led to the situation. 

Not sure it is relevant, but some of the themes were designed with > 8 bit
visuals in mind. Perhaps the theming problems are due to that. Regardless, if
-install isn't working on HP-UX, that is what we need to focus on understanding.
I'm not comfortable with doing this patch until I better understand the real
problem. (I might add, should that call be done only after querying the default
visual and determining that we are 8-bit? ifdefing HP-UX will have this code
called needlessly on 16-bit and greater visuals).

syd

Comment 7

[Martin Lawyer]

I will work on getting screen shots, but for now...

Bringing up mozilla on an 8-bit display after another graphic application (such
as Communicator 4.79) is already running, both the chrome and the browser render
area have messed up colors.  The "-install" option doesn't seem to make any
difference at any time, one way or the other (as if it is not "hooked up"). 

After this change, when mozilla launches, it detects that there aren't enough
colors, and installs it's own color map.  The other windows and desktop continue
to look and function normally.  

Also got the follwing info from Dan Dickerman via email:

----------
The GDK_WA_COLORMAP and rgb_get_cmap flags should choose whatever map the gdk
library selected when the rgb library was initialized, which would be the
private-installed map if the gdk_rgb_set_install(TRUE) was called (as suggested
by someone earlier in that bug, and as is done if the -install option is set),
and the default system colormap if possible.  Note also that if the gdk library
determines that there are not enough colors available in the default map to make
a decent color cube (not sure how "enough" is defined off the top of my head),
it will select a private map on its own.

If you've implemented the gdk_rgb_set_install(TRUE), in addition to the changes
I suggested, that would explain much, but I'm guessing that's not the case,
since you already mentioned the -install option.

So the real question is: when you don't specify the -install option, and
Mozilla's windows still choose a private colormap, is it the _right_ colormap,
or does the map now disagree with GTK?  If it's always the right map, I suspect
you are just below the threshold of available free colors, and that decision is
being made by the gdk_rgb library.  Checking the documentation for
gdk_rgb_init() for that threshold... "You can set the threshold for installing
colormaps with gdk_rgb_set_min_colors(). The default is 5x5x5 (125). If a
colorcube of this size or larger can be allocated in the default colormap, then
that's done. Otherwise, GdkRgb creates its own private colormap."

So, I suspect you don't have the requisite 125 free colormap entires -- seems a
lot to ask to have free out of 256, especially if you're running CDE or another
applicaiton which is quite the colormap hog.  If you suspect this is the case,
you might try starting with a simpler window manager (CDE's failsafe mode from
the login screen for example) so that more of the cmap is free when Mozilla
starts-up.  Alternately, instert a call to gdk_rgb_set_min_colors() before the
call to gdk_rgb_init in widget/src/gtk/nsAppShell.cpp passing a number smaller
than 125 (a 4x4x4 minimum cube would be set by passing 64, for example, or pass
8 or less to dither in black-and-white)."
-----------

Comment 8

[Syd Logan]

It's curious that --install is not being honored.

Could someone do the following? Run with --install, and use xwininfo to get the
colormap ID? 

Here's what I did on my Linux system:

[syd@localhost syd]$ xwininfo | grep -i Colormap
xwininfo: Window id: 0x1e0007a "Bug 160405 - Browser doesn't load private
colormap - Netscape {Build ID: 2002071509}"
  Colormap: 0x20 (installed)

Then, use xdpyinfo to see what the default colormap is:

[syd@localhost syd]$ xdpyinfo | grep -i colormap
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    64
    available colormap entries:    64 per subfield
    available colormap entries:    64 per subfield
    available colormap entries:    64 per subfield
    available colormap entries:    64 per subfield

If they are the same, then the --install is either ineffective, or it is ignored
(or being typed wrong on the command line).

Comment 9

[Martin Lawyer]

xdpyinfo output:
 number of colormaps:    minimum 1, maximum 2
 default colormap:    0x22
 default number of colormap cells:    256
   available colormap entries:    256
   available colormap entries:    8 per subfield


Mozilla running by itself:

Brought up with no command line options, looks good
Colormap: 0x22 (installed)

With '-install' or '--install' mozilla is green and semi-ugly
Colormap: 0x4400002 (installed)


With netscape 479 running before bringing up Mozilla:

With no options mozilla is brown and real ugly
Colormap: 0x4400002 (installed)

With '-install' or '--install' is yellow blue and real ugly
Colormap: 0x4400002 (installed)


These results are all without having any of the suggested changes applied. 

Comment 10

[Martin Lawyer]

Attachment: Mozilla running alone, no startup options:

Comment 11

[Martin Lawyer]

Attachment: Mozilla running alone, -install option:

Comment 12

[Martin Lawyer]

Attachment: Mozilla launched after Nav 4.79, no startup options:

Comment 13

[Martin Lawyer]

Attachment: Mozilla launched after Nav 4.79, -install option:

Comment 14

[Syd Logan]

Thanks for the screen shots, looks like a mess definitely. r=syd, please check
with blizzard for sr=

Comment 15

[Philip K. Warren]

We are taking a look at this bug to see if this patch fixes similar problems on 
AIX. I have seen similar problems with Mozilla on AIX running in 8-bit.

Comment 16

[Martin Lawyer]

Advice needed on this fix.

The patch I have attached is taken from the original bug 65881 comment #7: 
http://bugzilla.mozilla.org/show_bug.cgi?id=65881#c7

There is another change mentioned in that bug in comment #2:
http://bugzilla.mozilla.org/show_bug.cgi?id=65881#c2

Should I have included both changes in order to fix this properly?  

Note:  The original bug 65881 is still open to be fixed on the trunk.  This bug
report is filed only to get the changes from that bug into the OEM branch. 
Advice from the experts in this area definitely needed and appreciated.

Comment 17

[Martin Lawyer]

The change that I was worried about in bug 65881 comment #2 is actually already
added to the function nsAppShell::Create as part of checking for "-install"

-------
  rv = cmdLineArgs->GetCmdLineValue("-install", getter_Copies(cmdResult));
  if (NS_SUCCEEDED(rv) && cmdResult) {
    gdk_rgb_set_install(TRUE);
  }
-------

Since that change is in already, I think we should be good to go with the patch
as it stands now attached to this bug.  awaiting sr from blizzard? 

Comment 18

[Martin Lawyer]

Attachment: Patch updated to *not* be HPUX only

Comment 19

[Syd Logan]

I retract my r= if this is *not* for HP-UX only, until we have evidence that it
doesn't adversely affect all other unix platforms.

Comment 20

[Syd Logan]

I should add that I don't think this patch is going to be a problem, I just want
to hear about it having been applied and tested on other platforms against the
common (default) visuals.

Comment 21

[Martin Lawyer]

Attachment: HPUX only patch

Ok, let's go back to making it HPUX only for this release.

Comment 22

[Martin Lawyer]

I am contacting other platform owners asking them to test and approve this patch
for their platforms.  If there is no response, I agree that we should leave this
HP only. 

Comment 23

[Margaret Chan]

Hi Martin:

This is a long known problem for Solaris as well.  I did recall an old bug being
filed long long ago.  The feedback which we'd got before was that mozilla did
not support 8-bit display.  I will ask around or dig out some more info and get
back to you.

Margaret

Comment 24

[Jay Yan]

yes, Margaret, I also ever met with the misbehavoir of colormap in 8bit display
in Solaris, and there was some comments in the release notes. 
Silvia is now working on this bug on Solaris platform.

Comment 25

[Michael Lew]

This has also been a problem with AIX on systems with an 8bit color depth. I
have tested the fix on an AIX system and think it would be good to include it in
any AIX build as well.  I believe it improves the behavior of Mozilla.  We do
get the behavior where the other windows (and the desktop) lose their proper
color schemes when focus is placed inside the browser which I think is expected
for this platform.  So, as long as no unexpected/odd behaviors are discovered in
further testing, it'd be good to include this in AIX builds as well.

Comment 26

[Martin Lawyer]

Attachment: HPUX || AIX only patch

Adding AIX to the patch.

Comment 27

[Martin Lawyer]

Change checked in for HPUX and AIX, OEM branch only. 

Comment 28

[Bolian Yin]

Attachment: HPUX || AIX || SUNOS4 || SOLARIS patch

Matin's patch can also used for Sun Solaris.

Comment 29

[Bolian Yin]

checked in updated patch in NETSCAPE_7_0_OEM_BRANCH.

Comment 30

[Silvia Zhao]

I have applied the patch(id=95314) and tested on Solaris 9. Using this patch,
mozilla supports 8-bit display well.  :-)
Thx Bolian.

Comment 31

[Jim Dunn]

This should not be marked fixed until 
it is checked into the trunk.

Which you should do as soon as you get sr= from blizzard

Comment 32

[Martin Lawyer]

Bug 65881 is still open.

This bug was created as a copy of bug 65881 specifically for checkin to OEM
branch. I have sent email to the owner of bug 65881 (syd) proposing checkin of
this patch to the trunk (pending sr=blizzard) and closing both bugs.   

Comment 33

[Rick Takeda]

Changed QA Contact to Keith Tadej.

Comment 34

[Shanmugavelu Shanmuganathan (gone)]

Attachment: HPUX || AIX || SUNOS4 || SOLARIS || OSF1 patch

I would like have this patch for OSF1 too.

Comment 35

[Martin Lawyer]

Update to include OSF1 checked into OEM branch.

Comment 36

[Christopher Blizzard (:blizzard)]

Comment on attachment 95626 [details] [diff] [review]
HPUX || AIX || SUNOS4 || SOLARIS || OSF1 patch

sr=blizzard

Comment 37

[Keith Tadej]

Using a 20020827 build from the OEM branch, verified that when the
browser is launched when colors are being consumed by another
graphical application, a private colormap is used.
Colormap: 0x3800002 (installed)

Marking bug as VERIFIED - FIXED.

BUILD: 20020827 - OEM branch.
MACHINE: bologna - HP-UX 11.00 - (8-bit graphics)

Comment 38

[Jim Dunn]

reopening.
Keith, to mark this verified, you should
add verifiedOEM in the whitebar status
Fixed & Verified in the Status only applies to the trunk.
Martin, you need to get the latest patch (with osf & solaris)
into the trunk.

Comment 39

[Martin Lawyer]

Fix checked into trunk.

Comment 40

[Keith Tadej]

updating keyword to "verifiedOEM",
and marking "verified"