421961 - cursor position warp

Status: VERIFIED DUPLICATE of bug 288047

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Normand Dionne]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.12) Gecko/20080206 Camino/1.5.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.12) Gecko/20080206 Camino/1.5.5

When I need to make corrections in a  tex area , like this one for instance  , the cursorposition is out of aligment with the actual text making adjustment difficult.    For instance, if I want to delte a letter I must position the cursor one or two caharacters to the right of the target before hitting the delete key  n

Reproducible: Always

Steps to Reproduce:
1.Write text in area and try to change it after.
2.
3.
Actual Results:  
Had a hard time making corrections in the sentences

Expected Results:  
Normal text editing

Happens in all forms like this one on all websites

Comment 1

[Chris Lawson (gone)]

Make sure you aren't viewing Windows Media content in another tab with the Flip4Mac plugin, which is the usual cause of this sort of thing.

If you can reproduce this problem in a form with the form as the ONLY tab and ONLY window open in Camino, please let us know.

cl

Comment 2

[Normand Dionne]

Attachment: Screenshot of buggy text editing.

Yes I can reproduce it everytime with just one window and one tab on any webpage that offers this "fill form" feature.
Here is a screenshot of a web page with buggy text editing in the "Details" area.
Notice the cursor position of top of the "n"  Oops! the cursor does not appear in the screenshot.
Anyway, the cursor sits on top the character instead of to the right.
Also notice glyphs to the right of the line, this is after a backspace action over the word "warp" leaving traces of the characters used to write the word.

G5 dual PPC
OS X 10.5.2
Camino 1.5.5

Regards

Comment 3

[Stuart Morgan]

This isn't the F4M bug, this is a dup of another bug (which I can't find right now) about the cursor becoming progressively more offset horizontally when using certain fonts.

Comment 4

[Chris Lawson (gone)]

Yeah, I remember that one too, but I can't find it at the moment either...aha, there it is. This is almost certainly bug 288047, which I guess we can add a [10.5] tag to now :-\

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Normand, out of curiosity, what is your default monospace font in Camino?  (Your screenshot shows a san-serif font in fields that are set by the server to be monospace.)

I'd agree this is bug 288047....

Comment 6

[Normand Dionne]

The monospace font I was using when I reported the bug was Geeza Pro.
I have switched to Verdana when it was hinted that the issue might be font related. The text editing now behaves normally.
Thanks

Comment 7

[Normand Dionne]

I went to the Font Book app and had a look at Geeza Pro, it changes the alphabet into something that looks like it might be from India or the Middle East.
In the other apps where I use it , Geeza Pro behaves normally and is identical to Lucida Grande.