69599 - Caret invisible on 8-bit display, 256 color

Status: RESOLVED WONTFIX

(Core :: Graphics, defect, P2)

Description

[Christopher Beland]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-12 i686; en-US; 0.8) Gecko/20010220
BuildID:    2001022012

I'm using a variant of Gnome 1.2 on an 8-bit display.  Running nothing but
panel, it appears that Mozilla doesn't have enough colors to make the cursor
black.  Instead, it appears yellow, which on a while background, is nearly
impossible to read.  This happens in the navigation bar, in forms, and
everywhere else as far as I can tell.

Reproducible: Always
Steps to Reproduce:
1. Use Mozilla on an 8-bit display with Gnome Panel already running.
2. Click on nav bar as if typing in new URL.
3. Note lack of cursor.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Beland, two questions:

1) What theme are you using?

2) Are you talking about the mouse cursor or the text cursor (caret).  It sounds
like you mean the latter.

Comment 2

[Christopher Beland]

I'm using the Classic theme, though it also happens with Modern.

And yes, I'm referring to the text cursor.

Comment 3

[Patty Mac]

Beland, it seems this bug occurs in both Modern and Classic themes. Then 
the component needs to change, this is not a themes issue.

Comment 4

[Christopher Beland]

Shall I move it back to Browser-General?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Um... ok.  not themes.  Then XP Apps: GUI Features is the closest thing we have...

Confirmed, btw.  with 8-bit color under X the caret is nearly invisible.

Comment 6

[timeless]

i'd think toolkit would make more sense

Comment 7

[Blake Ross]

Simon, do you have any ideas?  We don't draw this at the xpapps level, so if 
it's not yours, send to toolkit or editor please.  pav might have some ideas.

Comment 8

[Simon Fraser [no longer active]]

This would seem to be a GFX issue (layout), since I just use its XOR mode 
(invert) to draw the caret.

Comment 9

[Sitsofe Wheeler]

This could be related to bug 34039...

Comment 10

[anthonyd]

not a table bug, reassigning to component owner.

Comment 11

[Kevin McCluskey (gone)]

Reassigning to Don.

Comment 12

[dcone (gone)]

I can not duplicate this on my machines.  Marking WFM.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Don, you _are_ using a Linux machine, right?  This is a Unix-only problem...

Comment 14

[dcone (gone)]

I tested on my Linux box.. maybee I have a different enviornment.. I dont know
that much about linux..

Comment 15

[Christopher Beland]

The critical feature about your environment is that the color depth of your
display be 8 bits (256 colors) or else this shouldn't be manifested.

Comment 16

[Frankie]

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

Comment 17

[Frankie]

Doesn't work for someone else.

Comment 18

[louis bennett]

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

Comment 19

[Wayne Mery (:wsmwk)]

do you still see this problem?
depends on bug 34039?

Comment 21

[Wayne Mery (:wsmwk)]

pretty much everyone who commented here is gone or not interested (see below), afaict. also marking dependent on bug 34039 based on reading and comment 8.

ooogster and temp6 are gone.
Christopher, reporter, writes "I can no longer test on an 8-bit display; in the 6 years since I reported this bug, I've acquired different hardware, and X now configures itself automatically to use more colors."

Comment 22

[Paul Townsend]

I still use 8-bit color.  Don't like 24-bit as, at times, the overhead on my box seems to be excessive and the colors seem to be wrong.  If a binary is generated that includes a fix for this problem, I'll test it.  I'd prefer to use the newer browsers but can't without a visible insertion caret.

Comment 23

[Wayne Mery (:wsmwk)]

Paul, how well do the dates of this bug square with you bug 332938 comment 3: "caret is visible with firefox1.0.7 and invisible with firefox1.5+ when using the 8-bit display mode."?  Does this bug of early 2001 far predate FF 1.5+?

Comment 24

[Paul Townsend]

The problem doesn't occur in any of the browsers based on the most recent variants of the 1.7 source tree, e.g., mozilla-1.7.x and firefox-1.0.x.  It occurs in the variants based on the 1.8 source tree only, e.g., firefox-1.5.x, firefox-2.x and seamonkey.  I first noticed the problem with the mozilla-1.8.x alpha and beta releases.

Comment 25

[Zack Weinberg (:zwol)]

This might still be relevant, but do we care about 8-bit color depth anymore?  I certainly have no way of testing at that depth (if there's something clever you can do with nested X servers, please let me know).

Comment 26

[Jeff Muizelaar [:jrmuizel]]

I do not believe we care to support 8 bit.