Closed Bug 180665 Opened 22 years ago Closed 13 years ago

cursor misplaced/won't reach end of line in proportional font styled textarea (caret)

Categories

(Core :: DOM: Editor, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mrmazda, Unassigned)

References

()

Details

(Whiteboard: fonts,testcase,[start at comment 35])

Attachments

(4 files)

2002111712 OS/2 trunk is currently running. I had to go back to 2002111408 OS/2
trunk to find a build I still had that doesn't have this bug. Bug present as of
evening of 15th. I also tried win32 2002111508 trunk, which works fine.

To reproduce:
1-Add a new comment to an existing bug, or open a new bug, and try to remove
characters at the end of a line in the description area using either the BS or
Del key

Actual behavior:
1-Cursor blinks near center of last character on line, or over a zombie
character if last character on line has been the target of a <BS> or <Del>. If
the last character on the line is a period or comma, the comma/period displays
to the right of the cursor.
2-Sometimes last character on line partially overlays next to last character on line

Expected behavior:
1-Cursor at end of line always displays to the right of the last character on
the line until forced to the next line by wrap or <enter>
2-Deleted characters are always removed from the screen

Comments:
1-FWIW, my current default font is 16px arial on 1024x768, which is what is
being used in text areas.
selection, not form controls
Assignee: form → mjudge
Component: Layout: Form Controls → Selection
QA Contact: tpreston → pmac
Part of this bug is a dup of 162349.  The part about zombie characters I don't
understand.  If you can describe that better then perhaps a different bug should
be opened against that. 

*** This bug has been marked as a duplicate of 162349 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
I read that bug before filing this, and it is not the same thing. For one thing,
that is a months old Mac-only bug, and this is a  48 hour old OS/2-only bug.
Second, there is no "sometimes" about this behavior. It appears immediately upon
attempting to change any last character on a line in a multirow form text area.
Comment 5 in bug 162349 does describe this behavior, but the duplication
circumstances are different. In particular, the past several days have seen
several OS/2-only fonts checkins.

As to the zombie character, you can see what I mean by booting OS/2 and trying
to use the BS and/or Del keys to change the last characters on a line. Once you
try, there will typically be a character advancing ahead of the cursor, until
you  make a space the last character, and insert in front of the space.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
There's another OS/2 bug for this.

*** This bug has been marked as a duplicate of 113194 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → DUPLICATE
I don't understand how a brand new behavior that is not identitical to behavior
in a year old bug can be the same thing. I read that bug, saw something
different, and filed a new bug. That bug's filer indicated failure to reproduce
and a connection to non-default sizes, more distinguishable characteristics.

The new behavior only happens at the ends of lines, while in bug 113194 the
mispositioned cursor apparently can happen any time. I've never seen bug 113194
behavior, while this behavior just started with Friday night's build. Here there
are never more than 1.5 characters to the right of the cursor.

Something I forgot to add originally is that the rightmost character on a line
is often invisibly located to the right of the right border of the text area.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
ok, thanks for clarifying.  When you have the invisible character beyond the
edge of the widget, is it always whitespace?  If so, that is by design.  The
alternative is for the space to show up leading the next line, and people really
hate that.
How do you have Arial as your font in text areas? It's supposed to be a
monospaced font.
jfrancis, the extra character beyond the boundary of which I wrote is never
whitespace. Until this bug, I wasn't aware that whitespace at the end of a
wrapped line was being "displayed".

MIke, I'm looking for your answer. I know part of it, but I'd like to find the
whole thing before reporting.
This bug's behavior was produced via userContent.css. I spent much time trying
to find the original source for what lead me to make the changes I made, and
couldn't do it. I think it was a newsgroup post, and Google has a problem
locating anything that includes "{" as a search criteria.

Before this gets marked invalid again, I'd like someone to provide at least some
explanation of the behavior to follow below. I'm in the early stages of learning
CSS, and I'm baffled why certain evidently size related keywords are required
after "font:" in order for the desired font face to be used, while the following
"font-size" is what determines the size of the font used in the text area.
Following close behind in bewildering me is the font face name case sensitivity.

I suspect it is just as likely the problem is that the userContent.css parser
has sanity checking shortcomings as it is that my inexperience with CSS is the
sole problem, and I also suspect just as likely it is a mixture of both.

In all test cases listed below, build ID is 2002111712, prefs for normal font is
16px arial, and monospaced font is set to System VIO 24 px. I did the latter
specifically to make the bug description area and the additional comments text
area different. My system has only system monospaced and courier as monospaced
font choices, and I hate courier with a passion. Likewise, system monospaced is
available in only one size (both too fat and too bold, besides too large),
leaving me a choice between terrible and worse.

Here are my test excerpts from userContent.css, with the first two being capable
of producing Arial in the text areas.

#userContent.css as it was when I filed this bug and Arial was resulting text
area font:
textarea {
    font: medium sysmono;
}
#Another way for userContent.css to produce Arial as text area font:
textarea {
   font: medium system monospaced;
   font-size: 16px;
}
#This userContent.css produces system monospaced:
textarea {
   font: medium System Monospaced;
}
#This userContent.css produces system monospaced:
textarea {
   font: medium System Monospaced;
   font-size: 16px;
}
#This userContent.css produces system monospaced:
textarea {
   font: medium System Proportional;
   font-size: 16px;
}
#This userContent.css produces System VIO:
textarea {
   font: System Proportional;
   font-size: 24px;
}
#This userContent.css produces System VIO:
textarea {
   font: System VIO;
   font-size: 16px;
}
#This userContent.css produces System VIO:
textarea {
   font: courier;
   font-size: 16px;
}
#This userContent.css produces 16px Courier:
textarea {
   font: medium Courier;
   font-size: 16px;
}
#This userContent.css produces System VIO:
textarea {
   font: Courier New;
   font-size: 16px;
}
#This userContent.css produces 10px Courier?:
textarea {
   font: medium Courier New;
   font-size: 10px;
}
#This userContent.css produces 12px Courier?:
textarea {
   font: large Courier New;
   font-size: 12px;
}
#This userContent.css produces 24px Courier?:
textarea {
   font: small Courier New;
   font-size: 24px;
}
#This userContent.css produces 18px System VIO:
textarea {
   font: light Courier New;
   font-size: 18px;
}
#This userContent.css produces 18px SystemVIO:
textarea {
   font: heavy Courier New;
   font-size: 18px;
}
> why certain evidently size related keywords are required after "font:"

I suggest reading the CSS spec, which clearly requires this:
http://www.w3.org/TR/CSS21/fonts.html#propdef-font

If you want to just set the font family, set "font-family" not "font".

> while the following "font-size" is what determines 

http://www.w3.org/TR/CSS21/cascade.html#cascading-order, item #4.

The case-sensitivity sounds like a bug in the OS2 gfx code.


This is still going to wind up invalid.

You picked Arial as your text area font.

Because of rounding errors in using truetype fonts, the cursor is off when moving.

This IS the same problem as that other bug.

I don't think it started recently. I think you changed your system to use Arial
for textareas recently.
Mike, I think you need to read comments 11 & 10 again. I never selected arial as
the text area font. Arial was used because userContent.css contained invalid
entries. The invalid userContent.css is what makes this bug as presented
invalid, but points out a different probable bug (last line in comment 11). I
would have invalidated this bug myself if I knew it wouldn't be just as well to
use it as a gfx (whatever that is) code bug.
There is still a difference in builds after 2002111408, as that build and those
prior ignored the invalid userContent.css textarea font syntax error, while the
later ones don't. NAICT, I first started fiddling with the textarea portion of
userContent.css precisely one month ago, and the problem only surfaced with
Saturday's first build.
Is there a way to effect/test userContent.css changes without shutting down and
restarting Mozilla?
Hardware: Other → PC
DOM inspector may work.  No other way.
Every line in your userContent.css is wrong, though. You are supposed to use
font-family, not font.
Moving to me so we can stop spamming Mike Judge
Assignee: mjudge → mkaply
Status: REOPENED → NEW
You also said you messed with your fonts recently. I should warn you that there
is an Arial bitmap font floating around and if you had used it instead of the
Arial TTF, you wouldn't have seen this problem.
You're still missing the point. I never selected Arial any place except in prefs
for proportional sans-serif.

Arial showed up in textarea as a result of defective userContent.css. Until I
read the links in comment 11, I didn't know the difference between font and
font-family. To the uneducated, the use of font-family rather than font implies
Mozilla can choose from a group of fonts rather than use only one specific font.

I still haven't located whatever it was that prompted me to make the changes I
made. Did you post last month on Usenet about how to change textarea font to
courier via userContent.css?

My system currently has only ttf Arial present in the system font palette. Are
you suggesting that adding to it the ari*.afm fonts from my Lotus Smartsuite
fonts directory might be good to do?

Does this bug need a summary change? Is this now a gfx code bug? The reported
problem disappeared upon removing invalid userContent.css code. 
> To the uneducated, the use of font-family rather than font implies

It implies that to the educated too, because it is true.

There is no invalid userContent.css code involved.  All the code is valid.

Again, the only issues I see here so far are (1) the text measurement issue
(mkaply says this is a font bug) and (2) the fact that we apparently do
case-sensitive matching on the family name on OS/2.
It was because of the inference that I specified font instead of font-family.

My reading of the first link provided in comment 11 requires a size to precede
the face. This is why I used the term invalid after finding apparent
corroboration in that the family name specified was not used when the size
parameter was omitted. Maybe the spec doesn't require it, but recent builds of
Mozilla apparently do.
Ah.  Well, the problem is that CSS does not have a concept of "invalid" CSS,
really.  There is only unknown CSS syntax from future CSS versions.
Our font code is NOT case sensitive. I would imagine the issue is probably the
lack of quotes around the font

"system monospaced"
Lightbulb! Quotes for font names that include spaces are what I failed to pick
up. But, that doesn't explain Arial resulting from:

textarea {
    font: medium sysmono;
}
Wouldn't use of system monospaced without quotes constitute invalid syntax
rather than unknown syntax?
sysmono would just be an unknown font so we would use your default font.

There is no sysmono
System -> Font Palette -> Edit Font -> Delete ->
     . . .
     lucti.ttf
     MARKSYM.OFM
     SYSMONO
     thonbi__.ttf
     thonburi.ttf
     . . .
That's a file name, that's not a font name.

Click on it. 

The font name is "System Monospaced"
OK, so where are we on this - do you still see it?
Can you check this with the Innotek stuff please?
I can no longer reproduce this with or without ft2lib, regardless which textarea
font I specify in userContent.css. Unlike before, the textarea box remains amply
wider than the text requires. Note that to "disable" ft2lib I merely copy the
original \mozilla\bin\components\gfx_os2.dll over the ft2lib version, leaving
the content of \OS2\DLL alone. -> WFM
Status: NEW → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → WORKSFORME
Here it is again in Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4)
Gecko/20030804 since marking WFM. Note last char on first line in the text area
is an "x", but you can see only half, and the cursor was over its center, right
at the textarea border.

Note that the textarea font is arial, while userContent.css specifies Comic
Sans thus:

textarea {font-family: 'comic sans ms' !important; font-size: 93% !important;
line-height: normal !important;}

which later is overridden by:

.comment {font-size: medium !important; font-family: sans-serif !important;
line-height: normal !important;}

This particular textarea has class selector "comment", but the page has no css
applied that includes a .comment rule.

What seems to be happening is that sizing is according to the 93% textarea
rule, while the font actually used is the later specified .comment rule,
medium/sans-serif. If this comment has spaces missing or extra between words,
it's because I'm experiencing this problem as I write.
Same scenario as previous attachment, but here instead is junk at the end of
the line that is unreachable via the keyboard. When you backspace, the cursor
moves, but the char is not deleted. This trash was removed by forced window
redraw, switching to another window and back.
Restarting with ft2lib installed produces considerable improvement, but not
perfection. 

The relationship of line length and box width becomes satisfactory.

If an "l" or "." or "," or other narrow character is the last character on a
line, the character is obsured by the cursor when blink state is on. With
typical width characters, the cursor blinks right on the right edge of the last
character, with absolutely no whitespace between, or maybe a tiny overlap.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The last paragraph in comment 35 also applies in W32 2003071814. OS->All

Going to try to produce a reduced testcase. . . .
Assignee: mkaply → mjudge
Status: REOPENED → NEW
OS: OS/2 → All
Summary: OS/2 - cursor won't reach end of line in text area → cursor won't reach end of line in text area (user css)
Attached file Testcase
Same problem on W98 in 1.5a and OS/2 in 1.4, somewhat to much worse in OS/2.
Testcsase includes instructions..
In comment 35, s/obsured/obscured/. In comment 33, ignore discussion of 
selector .comment.

Updating component, assignee, QA & summary to form controls. My best guess is
this is a _textarea_ styled with proportional fonts problem., but could be
editor: core as well.

Updating severity from minor to normal, as there is no easy workaround for the
textarea editing difficulty this creates when encountered.  In the wild URL
where you can see this http://gemal.dk/archives/000178.html added (../style.css
includes textarea {font-family: verdana,sans-serif;}). Another in the wild at
http://bugzilla.mozilla.org/attachment.cgi?bugid=180665&action=enter happens
with my user stylesheet rule:  textarea {font-family: 'comic sans ms' !important; }

It seems to me whatever is causing this is likely to be related to the cause of
bug 107086, and the rounding error mentioned in comment 12 here.
Assignee: mjudge → form
Severity: minor → normal
Component: Selection → Layout: Form Controls
QA Contact: pmac → ian
Summary: cursor won't reach end of line in text area (user css) → cursor misplaced/won't reach end of line in proportional font styled textarea (caret)
Whiteboard: fonts,testcase,[start at comment 35]
Using the testcase, I am unable to completely reproduce this on a fresh Mandrake
Linux 9.1 KDE 3 system without mswbfnts.zip contents installed.  I don't see any
overlapping of the last character by the cursor on any line, though the
whitespace between varies between slight and none.
caret issue -> Editor: Core (right?)
Assignee: form → mozeditor
Component: Layout: Form Controls → Editor: Core
QA Contact: ian → sairuh
QA Contact: bugzilla → editor
Assignee: mozeditor → nobody
Comment 35 WFM on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
Status: NEW → RESOLVED
Closed: 21 years ago13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: