53542 - Strange caret position in urlbar text box

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect, P3)

Description

[tenthumbs]

I hope I've got the right component; change it if I'm wrong.

I've been testing with a number of the standard X fonts and I've turned
up this anomaly. See the attached image and note the caret position.
Then note the caret position after I backspace three times.

For comparison, look at the Adobe Courier font. It appears much better
but look more closely and you'll see that the caret is actually sitting
over the last part of the past letter. Now this is with monospaced fonts
but proportional fonts also show problems. With the standard Helvetica
font, the caret is on top of the 'l' in "html".

This may or may not be related to bug 47582 which describes a vertical
alignment problem.

The images are from an 0918 build but an 0920 build does the same thing.

Comment 1

[tenthumbs]

Attachment: PNG image

Comment 2

[Peter Trudelle]

->editor

Comment 3

[rubydoo123]

this can wait till post-rtm

Comment 4

[rubydoo123]

giving this to anthonyd to look at post rtm

Comment 5

[anthonyd]

setting milestone to 0.9, want to try and pick this up for 6.5
anthonyd

ps.
also adding kin to cc list, since this may be related to one of his bugs (47582)

Comment 6

[anthonyd]

setting to p2
anthonyd

Comment 7

[rubydoo123]

moving to moz0.9.1, added correctness

Comment 8

[rubydoo123]

I wanted to capture in the bug a response I recieved from the reporter:
It's still there with a 2001-01-19-08 trunk build. I have screenshots if you
want them.

I discovered this because two things coincided:
1) I find it difficult to read proportional fonts in the urlbar and there too
small anyway so I have 

#urlbar {
  font-family: "Andale Mono",monospace !important;
  font-size: 12pt !important;
}

in userChrome.css.

The important point is using monospaced fonts. For my tests, Andale Mono
wasn't available and no default monospace font was specified so Mozilla found
the Bitstream font.

2) I've been testing Mozilla with a variety of font paths to see how it
performs. In particular, I tested how it works with no bitmap fonts available.
As you may know, Mozilla greatly prefers bitmap fonts over scalable ones.

You may have to reorder your X server's font path to see this, remove the
bitmap font paths, or specify the font directly. (BTW, it's very convenient to
run Mozilla in an Xnest server if you plan on messing with the font path.)

This font is also quite old so it's been around for a while and it works in
other apps. There doesn't seem to be anything particularly odd about its
metrics.

Now, normally, I would say this is just one particular font so why bother, but
it is included in all the X distributions so it will eventually be used.
Moreover, it is the only scalable Courier font in the normal distribution. I
would say it's necessary to determine what's going on here.

Comment 9

[Kathleen :Brade]

move to mozilla1.0

Comment 10

[rubydoo123]

--> kin

Comment 11

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 12

[Julien Moorrees]

Bug still appears in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1

Comment 13

[Julien Moorrees]

Attachment: DOUBLE, please remove

This bug still appears in the latest trunk:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1

Comment 14

[Julien Moorrees]

Attachment: Still appears in the latest trunk.

This bug still appears in the latest trunk:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1

I tried to select the "."-sign of the url.

Comment 15

[Julien Moorrees]

Related: https://bugzilla.mozilla.org/show_bug.cgi?id=334627

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that this was caused by the old gfx and the old nsTextFrame. I mark this as WFM. Please reopen a new bug as text layout issue if you still see similar issue.