Created attachment 88920 [details]
Screenshot showing the problem

What X driver are you using? That looks like it could be an X driver or Xft issue...

I'm using a GeForce 4 Ti4600 in 1024*768*24 bit color mode.

My setup of Phoebe is still a out-of-the-box one.

I'll attach my "XFree86.0.log" to this Bugzilla.

I'll experiment with using different drivers / screenresolution combinations to
check if this also
occurs in those configurations and report about the results.

I had not this problem with Red Hat 8.0 using the NVidia drivers from the NVidia
site. Maybe if time permits I'll try those NVidia drivers too, but for me that
is tricky because of the installation steps involved (They 'hardcode' their
drivers for a specific version of Red Hat Linux and 8.1 beta 1 is probably not
supported yet).

Created attachment 89026 [details]
My XFree86 log file

I have tried a couple of things :

First I tried different combinations off resolutions & color depth with the
nvidia driver; that did not help. There was still the 'pixel-smearing' to be
seen inside Mozilla text entry boxes.

I then tried the 'vesa' driver (using redhat-config-xfree86) with 1024*768*24
bit. Boy, what a difference that was!

The first thing I noticed was the mouse cursor. 

With the 'nvidia' driver the color of the mouse cursor was transparant and
somewhere between light grey and dark grey.

With the 'vesa' driver the color of the mouse cursor was white (as it should be
- I guess) and the 'pixel-smearing' inside Mozilla text entry boxes completely
dissapeared!

This is obviously a nvidia driver issue.

I'll attach my XFree86 log file of the nvidia driver to this Bugzilla.

Source RPM: XFree86-4.2.99.2-0.20021217.0.src.rpm

Created attachment 89027 [details]
XFree86 logfile of vesa driver on GeForce 4 card

You mention above that the "vesa" driver works ok, and have attached the
log file from the working vesa driver.  Could you attach the log file
and config file from the non-working driver instead?

Also please read bug #73733 concerning the Nvidia proprietary driver.

If you're using the "nv" driver, perhaps it is a 2D acceleration issue,
or it could even just be a mozilla bug.

Adding Chris Blizzard to CC

Created attachment 89123 [details]
XFree86 logfile of nvidia driver on GeForce 4 card

Created attachment 89124 [details]
XFree86 4 configuration file of Nvidia GeForce 4

Oops, I closed instead of duped.

*** This bug has been marked as a duplicate of 73733 ***

The comments and log files above clearly indicate that the misbehavior
is with the open source 'nv' driver, not the proprietary nvivdia driver.

Sorry for the confusion. The last comment by Owen Taylor is correct. I have not
tried the Nvidia closed source driver yet (on Phoebe 8.0.92). The described
problem occurs with the open source Nvidia (nv) driver and not with the open
source vesa driver.

Package : XFree86-4.2.99.2-0.20021217.0

I just discovered that Ximian Evolution also has this same problem. It has this
same problem in the 'compose new message' entry screen. So it's not a Mozilla
thing. 

"kedit" (qt3?) and "gedit" (gtk2?) don't have this problem. The problem might be
caused by some shared library being used by both Mozilla and Ximian Evolution in
combination with the open source 'nv' driver / module.

Package : evolution-1.2.1-2

Again, sorry for the confusion. I should have said "nv" where I said 'nvidia'.
I'll play with the options in the "nv" configuration file to see if described
problem goes away; if I find anything interesting to report, I'll attach my
logfiles to this bugzilla. Thanks!

Some interesting news.

First of all, I'll change the subject from this Bugzilla:

from : "Using cursor keys in Mozilla textboxes leaves 'smearing' with nvidia
driver".
to : "Using cursor keys in textboxes results in 'pixel smearing' with opensource
"nv" driver.

Okay, I've followed Mike's advice (in comment # 18) and did the following :

I inserted the line :

    Option      "noaccel" "on"

in the file "/etc/X11/XF86Config". I did this in the section called "Device".
This action solved all reported problems (the pixel mess in textboxes of both
Mozilla and Evolution), but introduced much slowness with full-window dragging.

I then followed his advice with the XaaNo* options, which I retrieved from the
manpage with the following command :

     "man XF86Config |col -b |grep -i XaaNo"

I copy & pasted the result of this command in the "/etc/X11/XF86Config" file,
under the "Device" section and deleted the line with the option "Noaccel". I
also commented every 'XaaNo' option generated by the above command. I then
deleted the commented character of the option :
                
         Option      "XaaNoSolidTwoPointLine" "on" 

and did a restart of the X server.

By starting Evolution and bringing up the 'compose new message' option I did try
using the cursor keys in the text entry of Evolution's compose window. The
reported problem did not occur. To be sure that the option
"XaaNoSolidTwoPointLine" was the cause of this, I commented it again and
restarted the X server. The reported problem returned again. I then deleted the
comment char of "XaaNoSolidTwoPointLine" and tried, after restarting X, the
cursor key test in Evolution again. And ..... the reported problem did not occur.

So, I then tried Mozilla's text entry box on RH Bugzilla. Strangely Mozilla
still had this problem. So with the option "XaaNoSolidTwoPointLine" the problem
disappeared with Evolution but still occurred with Mozilla textboxes.

I'll attach the config & log files of the 3 times in a row reproduced situation
with Evolution to this Bugzilla. Due to lack of time at the moment for me, I
cannot try all options to check out Mozilla's problem.

I'll attach the config & logfiles with the open source "nv" driver with the
"noaccel" option on and off.

I'll also attach the config & logfiles with the open source "nv" driver with the
"XaaNoSolidTwoPointLine" option on and off.

Created attachment 89268 [details]
XF86 config file which has no problems with Evolution

Created attachment 89269 [details]
XF86 Config file with the noaccel option

Created attachment 89270 [details]
XF86 config file with problems in Mozilla and Evolution

Created attachment 89271 [details]
XF86 logfile without probs in Evolution

Created attachment 89272 [details]
XF86 log file with noaccel option

Created attachment 89273 [details]
XF86 log file with probs in both Mozilla and Evolution

The correct option to fix Mozilla when using the open source "nv" driver is:
        Option "XaaNoSolidFillRect"

When using just this option Evolution still has the pixel corruption issue. So I
added the entry above of:
	Option "XaaNoSolidTwoPointLine"

These two options combined fix both Mozilla and Evolution.

On my system both these options fix the pixel corruption problem in Evolution
and Mozilla also.

Ok thanks.  I'll set the config file defaults to use the following options
for now, and I'll inform the upstream "nv" driver maintainer as well.

    Option "XaaNoSolidFillRect"
    Option "XaaNoSolidTwoPointLine"

I've reported this to the upstream driver maintainer, and here is
his suggestion:

>I've got well over a dozen cards and haven't seen any problems
>with those two primitives.  Who made that card and what's its
>BIOS version?  Could be a broken card, but it's more like that
>it just POSTs with the clocks too low.

Could you please provide the card manufacturer's name, BIOS version,
and also check and see if they've got a newer BIOS as well.

Leadtek Research Inc.
GeForce3 Ti 500
BIOS: 3.20.00.18
Product: NV20 Board
Version Chip Rev A3

I'll test out the new refrence BIOS 3.20.00.20 and see if that fixes the issue.

Micro-Star International
GeForce3 Ti 200
BIOS: 3.20.00.16.25
Product: NV20 Board
Version Chip Rev A3

This GF3 also has the pixel corruption issue, I tried the latest reference BIOS
for this model 3.20.00.18 and it still had the issue after the update.

I've also tested on a:
Dell Inspiron 8000 Laptop
GeForce2Go 
BIOS: 3.11.01.44.B4

This system appears to work perfectly without any Xaa options needing to be set,
is this bug perhaps limited to GeForce3 models?
 

>Leadtek Research Inc.
>GeForce3 Ti 500
BIOS 3.20.00.20

The pixel corruption still occurs with the latest BIOS

I have the same problem... using the opensource "nv" driver..

VisionTEK
G-Force 4 - Ti4600

I am not sure where to find the BIOS version (and since I am in initdefault 3, I
can't find the log file (isn't that somewhere in /tmp?) ... The only place I
remember seeing the Bios version is during a reboot (which I wont be able to see
from here)

(lspci)
01:05.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti4600]
(rev a3)01:05.0 VGA 

(lspci -v)
compatible controller: nVidia Corporation NV25 [GeForce4 Ti4600] (rev a3)
(prog-if 00 [VGA])
	Subsystem: VISIONTEK: Unknown device 0037
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 17
	Memory at 52000000 (32-bit, non-prefetchable) [size=16M]
	Memory at c0000000 (32-bit, prefetchable) [size=128M]
	Memory at c8000000 (32-bit, prefetchable) [size=512K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [60] Power Management version 2
	Capabilities: [44] AGP version 2.0



If I can provide any more information, please let me know.

Tommy

Okay, here's my card :

Manufacturer : MSI
Card : NVidia GeForce 4 Ti4600
Model name : MS-8872
BIOS version : 4.25.00.22.52

"lspci -v -v" gives :

01:00.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti4600]
(rev a2) (prog-if 00 [VGA])
        Subsystem: nVidia Corporation: Unknown device 0130
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at de000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
        Region 2: Memory at ddc80000 (32-bit, prefetchable) [size=512K]
        Expansion ROM at dfee0000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 2.0
                Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

The driver maintainer says he can't reproduce this, however I've sent
him the information you've provided above in hopes he might have some
idea after seeing your updates.

If he's still unable to reproduce this after that however, I would be
inclined to believe that this is either a Mozilla bug, or an Xft bug.

It's rather hard to say.  It doesn't reproduce on any ATI or Matrox
hardware that I have here.  I've got a Quadro 2 and a Quadro 4 here
that I can test as well though.

Please also make absolutely sure that you are all running the absolute
latest beta (phoebe second release) and the latest Mozilla, evolution,
XFree86, freetype, fontconfig, and other software updates.

Please continue to provide more information and testing results as well.

Could each of you provide the Mozilla version that you're using here too?

I have great difficulty believing that this isn't either:

1) A driver bug

or

2) A hardware bug or hardware not properly producing lines that match
   what fb draws.

Since the problem goes away with disabling acceleration, I can't think
of anything that could cause this to _not_ be driver related.

And.....  <drumroll>

I was right.  The 'nv' driver maintainer received more bug reports from
other people, and looked into it deeper, and determined that the problem
did occur on some hardware and was due to the BIOS posting with clocks
low on some hardware.  He has committed a change to CVS to try to address
this:

Date: Wed, 12 Feb 2003 13:26:28 -0800 (PST)
From: Mark Vojkovich <mvojkovi>
To: cvs-commit
List-Id: CVS commit messages from the XFree86 repository <cvs-commit.XFree86.Org>
Subject: CVS Update: xc (branch: trunk)
 
CVSROOT:        /home/x-cvs
Module name:    xc
Changes by:     mvojkovi.org.    03/02/12 13:26:28
 
Log message:
     Use GXCOPY_ONLY for solid fills on newer NVIDIA cards.  The bios
  posts with the clocks too low to accelerate this without corruption.
 
Modified files:
      xc/programs/Xserver/hw/xfree86/drivers/nv/:
        nv_xaa.c
 
  Revision      Changes    Path
  1.29          +13 -103   xc/programs/Xserver/hw/xfree86/drivers/nv/nv_xaa.c

This issue is fixed in the latest Phoebe beta3 (8.0.94)

The work-around is no longer necessary for Mozilla, or Evolution

Thanks