126066 - Changing caret (cursor) color

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Gtk, defect)

Description

[ibelooze]

When I compose messages in a window, such as replying in a forum, the cursor is
nearly invisible, it is a shade darker than white with no apparent way to adjust
it. Also would like to make the cursor a block one instead of the vertical line
like it is now. Or at least the same color as the text, like in Netscape 4.6.

Comment 1

[R.K.Aa.]

Assuming you mean the caret: Are you using a GTK themes? Does the caret color
change if you change to another theme?

Please also include Mozilla build ID.

WFM, current CVS Linux, GTK theme "Raleigh": Caret blinks white/black, easy to see.

Comment 2

[sujay]

Esther/nbaca, can you reproduce?

Comment 3

[Kathleen :Brade]

-->selection

I recommend this bug be resolved as invalid unless we get more information such
as build ID, OS version / (windowing software), etc.

Comment 4

[Sven Rudolph]

I have the same (or a very similiar) problem. In the the URL input field, in
HTML input fields and in mail composing the curser blinks in a very light gray
(on white background), so it is nearly invisible.

I use 1.1 and 1.2.1 on Linux with the classic theme. The X Server (on an NCD X
Terminal) runs in PseudoColor, so I guess that Mozilla didn't find enough 
free entries in the color palette. At least the real black that is used for text
should be available, so the fallback should go to this color.

(I use Debian GNU/Linux and its Mozilla Package 1.2.1-8)

Comment 5

[Clay Collier]

I'm getting this same bug running Mozilla 1.2.1 on FreeBDS (Mozilla/5.0 (X11; U;
FreeBSD i386; en-US; rv:1.2.1) Gecko/20030227).  In textboxes and the location
bar, the caret is almost invisible- simply a very light shade of gray.  I'm
running Sawfish and using the MicroGUI theme.  OS is FreeBSD 4.7-Release

Comment 6

[Philip K. Warren]

This bug is also very easy to reproduce on AIX machines with low color displays.
The color of the text cursor is drawn in either a light gray or light yellow
color, and this also causes several problems with highlighted text, like in a
XIM preedit string.

I was able to get better behavior by changing the GDK function from GDK_INVERT
to GDK_XOR in nsRenderingContextGTK::InvertRect(), however this is the opposite
of the change made in Bug 17968.

Comment 7

[Philip K. Warren]

The screen shot in Bug 17968
(http://bugzilla.mozilla.org/attachment.cgi?id=6473&action=view) shouldn't occur
with normal selected text today because we are using DrawSelectionIterator in
nsTextFrame to ensure that multiply selected text is displayed with the correct
contrasting colors.

This is not being done for the caret cursor or any of the XIM selection styles
however (SELECTION_IME_SELECTEDRAWTEXT, SELECTION_IME_RAWINPUT,
SELECTION_IME_SELECTEDCONVERTEDTEXT, SELECTION_IME_CONVERTEDTEXT).

Comment 8

[Philip K. Warren]

Attachment: Patch v1

This changes the GDK function used in InvertRect back to GDK_XOR. This should
be a relatively harmless fix (as InvertRect is no longer used for regular
selected text), and it seems to improve the contrast of the text
cursor/background and XIM selected text on low color displays.

Comment 9

[Christopher Blizzard (:blizzard)]

Can you give me a quick screenshot of the difference?

Comment 10

[Philip K. Warren]

Attachment: GDK_INVERT screenshot

Comment 11

[Philip K. Warren]

Attachment: GDK_XOR screenshot

Comment 12

[Philip K. Warren]

The GDK_INVERT behavior gets much worse if more applications are open. In this
screenshot, it is not horrible but the GDK_XOR contrast is much better. With
more applications open, the GDK_INVERT may choose a light yellow background and
a white foreground, which is almost impossible to see.

Comment 13

[Philip K. Warren]

Fixed.

Checking in nsRenderingContextGTK.cpp;
/cvsroot/mozilla/gfx/src/gtk/nsRenderingContextGTK.cpp,v  <-- 
nsRenderingContextGTK.cpp
new revision: 1.182; previous revision: 1.181
done

Comment 14

[Philip K. Warren]

I backed out this fix because I found that it broke displaying of -moz-outline:
invert.

Comment 15

[Philip K. Warren]

Attachment: -moz-outline testcase

Comment 16

[Roland Mainz]

Philip K. Warren (IBM) wrote:
> I backed out this fix because I found that it broke displaying of 
> -moz-outline: invert.

What about adding a new method to nsIRenderingContext which implements the XOR
functionality (and falls back to "invert" when the specific platform has no
special implementation for that) ?

Comment 17

[Philip K. Warren]

Attachment: Patch v2

This fixes the problem with the -moz-outline: invert usage, and still provides
the benefits of increased contrast between IME selected text and the cursor on
low color displays.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 151461 [details] [diff] [review]
Patch v2

InvertRect should just invert the rect.  It shouldn't depend on the current
color.	nsRenderingContextGTK::InvertRect should be fixed so saves and restores
the current color if that matters (and likewise for any other implementations).

Comment 19

[Philip K. Warren]

Attachment: Patch v3

Comment 20

[Philip K. Warren]

Latest patch checked in. Marking fixed.

Checking in gtk/nsRenderingContextGTK.cpp;
/cvsroot/mozilla/gfx/src/gtk/nsRenderingContextGTK.cpp,v  <-- 
nsRenderingContextGTK.cpp
new revision: 1.184; previous revision: 1.183
done
Checking in xlib/nsRenderingContextXlib.cpp;
/cvsroot/mozilla/gfx/src/xlib/nsRenderingContextXlib.cpp,v  <-- 
nsRenderingContextXlib.cpp
new revision: 1.103; previous revision: 1.102
done