Closed Bug 98564 Opened 23 years ago Closed 20 years ago

caret overlaps the last character in textfield (if positioned after the last char)

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla1.5beta

People

(Reporter: sujay, Assigned: kinmoz)

References

Details

(4 keywords, Whiteboard: [caret][QAHP] EDITORBASE+ edt_x3)

Attachments

(3 files, 2 obsolete files)

build:2000081105m18

Dunno if this should go in Themes component or Editor. Pls reassign if 
incorrect.

Steps:
1. Switch theme from modern to classic from under the prefs dialog.
2. Type some url, say, www.yahoo.com in the url textfield
3. Observe that the cursor blinks right on top of the last character's right 
border making it somewhat unreadable. 
This does not happen under modern skin or 4.x browser.



------- Additional Comments From beppe@netscape.com 2000-08-11 15:10 -------

moving this to m19, will see if our intern can take a look at this one



------- Additional Comments From Ryan Cassin 2000-08-11 15:17 -------

I'll take a look at this one



------- Additional Comments From Ryan Cassin 2000-08-13 08:44 -------

This bug belongs in the Themes component because the issue isn't confined to 
the Editor. Any text field throughout Mozilla has this issue.



------- Additional Comments From leger@netscape.com 2000-08-17 12:38 -------

Adding classic keyword



------- Additional Comments From Michael Kaply 2001-02-12 10:06 -------

I don't believe this is Classic only.

In Modern, If I put a lowercase "L" in the URL bar, the lowercase l blinks as 
the cursor.

This is a general problem.



------- Additional Comments From Michael Kaply 2001-02-12 10:06 -------

*** Bug 64499 has been marked as a duplicate of this bug. ***



------- Additional Comments From achimha@innotek.de 2001-02-12 10:11 -------

I can confirm it in Modern. Go to Search -> Find in this page -> enter the
letter
"l" and you will see it overlap with the I beam cursor.



------- Additional Comments From shrirang khanzode 2001-03-21 08:36 -------

*** Bug 72778 has been marked as a duplicate of this bug. ***



------- Additional Comments From sujay@netscape.com 2001-03-21 08:39 -------

Lets set a target milestone for this bug....so we don't see this problem
in modern theme?



------- Additional Comments From shrirang khanzode 2001-03-21 08:40 -------

it's everywhere..it's a general problem



------- Additional Comments From sujay@netscape.com 2001-03-21 08:57 -------

Okay 3 things on this bug:

1) Its not a themes bug, because its happening under both themes.
   So I'm changing it back to Editor

2) This bug was assigned to a summer intern who is no longer here,
   and he didn't take care of it, so I'm changing it back to "beppe" as
the         Assigned To.

3) We need a target milestone for this bug. 



------- Additional Comments From sujay@netscape.com 2001-03-21 09:01 -------

changing summary.



------- Additional Comments From sujay@netscape.com 2001-03-21 10:11 -------

oops, ignore my comment about summer intern below...actually Ryan
is still working for mozilla now....adding him back to Cc: list..

Ryan, whats the status on this bug ? thanks!



------- Additional Comments From Ryan Cassin 2001-03-21 14:28 -------

Under any Mozilla dialog box in both the Modern and Classic themes, this bug is 
no longer valid. In any URL field or find dialog the "m" in www.yahoo.com is no 
longer overlapped by the cursor.

However in normal text entry in the editor (in the body of a document) the 
cursor overlaps the text (for example, the "m" in www.yahoo.com is overlapped)

I think we should mark this bug WORKSFORME and open a new one which explains 
this problem.



------- Additional Comments From shrirang khanzode 2001-03-21 14:33 -------

i had mentioned that the 'right border of the last character is getting 
overlapped by the caret', which is still happening clearly.



------- Additional Comments From sujay@netscape.com 2001-03-21 14:40 -------

Lets not mark this bug WORKSFORME, we all are still seeing the original problem.




------- Additional Comments From selmer@netscape.com 2001-03-22 06:45 -------

Ryan, the exact problem described in the summary of this bug still happens.  As
noted, it also happens in other places (prompting me to file bug 72778 which was
duped against this bug.)  Can you update the bug's status and milestone?  If
this isn't happening before beta, I need to see if it's priority should be
raised.  Thx, Steve



------- Additional Comments From beppe@netscape.com 2001-03-29 15:23 -------

assigning to Simon to take a look at



------- Additional Comments From Simon Fraser 2001-04-11 18:52 -------

When the caret is 1 pixel wide, as it is for the URL bar and all single line
text 
widgets, it shows in exactly the same location as it does in Wordpad, with 
similar font settings. When at the end of the line, it only overlaps the last 
character if that character slopes to the right (e.g. a '/'); a lower case 'L'
is 
not obscured.

When the caret is 2 pixels wide, as it is for Composer, then some character 
overlap occurs, but not to the extent that it impairs usability. If you
disagree, 
please reopen, but be sure to state the exact conditions under which this
overlap 
occurs.



------- Additional Comments From Simon Fraser 2001-04-11 19:07 -------

Note that bug 64276 also covers this issue.



------- Additional Comments From selmer@netscape.com 2001-04-12 10:47 -------

Reopening since there was no fix and the problem still exists.  Perhaps you'd
rather have 72778 reopened instead, but I'm reopening this since 72778 was dup'd
here.

To easily reproduce this behavior in the 4/11 04 build, goto mail, hit the
NewMsg button, type a single lower case 'j' in the first address field and then
watch it blink down to 2 or 3 pixels with the input cursor.  The letter 'j' does
*not* slope to the right, but is almost entirely obscured.

Now, do this exact same thing in 4.x.  You'll find a very nice noticable gap
between the entire letter 'j' and the input cursor.  Marking 4xp.

Hmmm.  The fonts are very different for some reason.  The 'j' in the 6.x mail
addr widget does not have the horizontal bar at the top.  Also, adding a letter
after the 'j' and then using the arrow keys to go back and forth positions the
input cursor differently than just typing the 'j' by itself.  This is also
different from 4.x where the input cursor always goes back to the original spot.
 It may be that this whole bug is about the input cursor being off by 1 pixel
during *text input*.



------- Additional Comments From Simon Fraser 2001-04-12 12:04 -------

*** Bug 64276 has been marked as a duplicate of this bug. ***



------- Additional Comments From Simon Fraser 2001-04-12 12:06 -------

What's odd is that on my NT box, the caret position is the same on 4.x and 
Mozilla. On shrir's NT box, I do see the caret overlap, which I agree is bad.

This is going to turn out to be dependent on nasty rounding errors and font 
metric differences, I think. I'll see what I can do.



------- Additional Comments From Simon Fraser 2001-04-14 22:48 -------

*** Bug 76076 has been marked as a duplicate of this bug. ***



------- Additional Comments From Simon Fraser 2001-04-14 22:49 -------

Comment from jrgm in bug 76076:

There is a dependence on the font for this. At the end of a line, the position
is
correct for the default serif font, and off to the left by one for sans-serif
and monospace for my win2k system. On Mac,  serif and sans-serif are off, but
monospace is ok (I think; didn't have a magnifier handy on Mac).

But then when it is in the middle of a line, on win2k, serif is off by one to
the right, while monospace and sans-serif exactly split the characters. (and
mac, 
is
monospace off by one, and serif and sans-serif OK).




------- Additional Comments From scalkins@netscape.com 2001-04-17 16:57 -------

This affects IM Compose as well
setting Mostfreq keyword also



------- Additional Comments From gail@netscape.com 2001-04-17 17:46 -------

Created an attachment (id=31248)
extreeme close-up.



------- Additional Comments From Jesse Ruderman 2001-04-17 18:47 -------

That screenshot seems to show the opposite problem: the caret overlaps with the 
character to the *right* when it's in the middle of text.  I think the caret is 
in the correct place when it's in the middle of text; it's just too thick.  In 
bug 39529 it looks like some Composer people decided that the caret should be 
two pixels thick in Composer but one pixel thick in the location bar.  Anyway, 
I think that's a separate problem.  If you file a new bug for that problem, 
please mention the bug number here.



------- Additional Comments From Jesse Ruderman 2001-04-17 18:48 -------

From dup bug 76076, this is for all textfields, not just the location bar.  
Updating summary.



------- Additional Comments From Gervase Markham 2001-04-18 03:31 -------

Not even close to mostfreq (although still _very_ annoying.) You need around 10 
dupes, and this has two.

But, while I'm here, could I put a vote in for this being fixed as soon as 
possible? :-)

Gerv



------- Additional Comments From selmer@netscape.com 2001-04-19 23:49 -------

Jesse, Gail's image shows just one way this manifests.  The overlap problem
varies depending on what you've done so far.  If you're entering text then it
overlaps the last character.  If you cursor around, then it seems to get off
track and can show up like the attached image.



------- Additional Comments From John Morrison 2001-04-27 16:21 -------

*** Bug 77952 has been marked as a duplicate of this bug. ***



------- Additional Comments From beppe@netscape.com 2001-05-03 14:19 -------

moving to 1.0 per triage meeting, still reproducible, but not impacting 
funcitonality



------- Additional Comments From brade@netscape.com 2001-05-08 08:37 -------

*** Bug 79405 has been marked as a duplicate of this bug. ***



------- Additional Comments From gail@netscape.com 2001-05-29 13:54 -------

This really needs to get fixed. Anybody working on this? 



------- Additional Comments From Anatoliy Averbukh 2001-06-08 09:43 -------

I think, I have found exact conditions, when overlap arises.

In fact, it is not just problem with last character (changing summary). It 
happens for all characters for any character position for just SMALL size and 
VARIABLE width fonts.

If we use font with bigger size or fixed one, there is NO problem at all. 
However, for SMALL and VARIABLE font size, the problem persists.

Unfortunately, default font size for all editor applications (including and 
composer itself) is small enough and VARIABLE, 
and so users can watch the overlap (that really little thing could confuse 
them).

I agree with Simon, it happened, because caret width for small fonts is big 
enough for those small and variable fonts.

One pixel wide caret (instead of 2 pixels, as it is today) would be OK for 
that, and could solve the problem (including and corresponding bugscape bug, 
this bug blocks it).

Is it possible to fix that for m0.9.2?

New summary would be:
CARET OVERLAPS IN TEXTFIELDS FOR SMALL SIZE AND VARIABLE FONTS



------- Additional Comments From Simon Fraser 2001-06-11 11:45 -------

This blocks a bugscape (4673) bug which is 0.9.2



------- Additional Comments From Simon Fraser 2001-06-11 14:30 -------

Can someone please give me a specific font/size combination for which they see 
poor caret positioning, on an NT box? Things look fine to me, even using small 
font sizes in Times New Roman. A testcase document would be good.



------- Additional Comments From Anatoliy Averbukh 2001-06-11 15:43 -------

From prefs:

Proportional = Serif
Serif = Times New Roman, size 16

From Format menu:
font = Variable Width (just for variable, for Fixed font, all is OK),
size = medium



------- Additional Comments From Simon Fraser 2001-06-11 17:25 -------

I figured out why this is happening. Some code I added to keep the caret within 
the text frame (to avoid caret turds) is pushing the caret to the left when it's 
at the end of a frame.

So we need to figure out how to draw the caret anywhere we like, without leaving 
turds. That problem has plagued the caret all along......



------- Additional Comments From Jesse Ruderman 2001-06-17 18:23 -------

*** Bug 86301 has been marked as a duplicate of this bug. ***



------- Additional Comments From Simon Fraser 2001-06-19 12:05 -------

Not gonna get to this by 0.9.2, alas.



------- Additional Comments From beppe@netscape.com 2001-06-27 11:22 -------

this is a risky fix for the current milestone, could intor lots of cruft, moving 
to 1.0



------- Additional Comments From brade@netscape.com 2001-08-24 10:49 -------

*** Bug 96755 has been marked as a duplicate of this bug. ***



------- Additional Comments From brade@netscape.com 2001-08-24 10:53 -------

From another bug (comments from beppe):
this was done so when the user is in a textarea or textfield, the caret is not 
lost under the edge of the box, in other cases the caret could end up outside
the 
textframe which would result in caret cruft on the screen



------- Additional Comments From Madhur Bhatia 2001-08-24 12:15 -------

similar bug was bug 19180



------- Additional Comments From selmer@netscape.com 2001-08-24 18:51 -------

responding to beppe's comment on 8/24: shouldn't the placement of the caret
always be the same and instead truncate the number of characters shown in the
field to ensure the caret *can't* fall in any of the bad places?
Severity: normal → major
Keywords: 4xp, nsCatFood
Whiteboard: [caret][QAHP]
Target Milestone: --- → mozilla1.0
*** Bug 48602 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Blocks: 104166
Whiteboard: [caret][QAHP] → [caret][QAHP] EDITORBASE
Whups, running with that for a while I realized that Unix browsers don't
normally stop at punctuation by default (it makes life difficult in the urlbar)
even though many editors do.  Added the following to unix.js:

Index: unix/unix.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/unix/unix.js,v
retrieving revision 3.49
diff -r3.49 unix.js
70a71,73
> // override double-click word selection behavior.
> pref("layout.word_select.stop_at_punctuation", false);
> 
Sorry, wrong bug.  I have no idea why that comment ended up in this bug.
Marking nsbeta1+ per syd. Need to fix for composer usability.
Keywords: nsbeta1+
Whiteboard: [caret][QAHP] EDITORBASE → [caret][QAHP] EDITORBASE-
*** Bug 107905 has been marked as a duplicate of this bug. ***
Agree, not EDITORBASE. Classic is not the default skin.
Whiteboard: [caret][QAHP] EDITORBASE- → [caret][QAHP]
This bug still exists, it's one of the oldest I know and one of the bugs that
annoy me most. Currently I'm using Build ID 2002011908 (Win98) and the status of
the bug is:

It happens in the address bar, where the caret has a width of one pixel and it
overlaps one pixel with the last character (e.g. i is overlapped as a whole in
the address bar). It seems to always happen, regarless of what the last
character is.

It happens in every text area, where the caret has a width of two pixels and
sometimes overlaps two pixel with the last character (e.g. in case of 'm'),
sometimes only one pixel (in case of '/'), but sometimes not at all (in case of
')' or '.'). In text fields it sometimes also overlaps a character in the middle
of a word. E.g. in case of 'ad' it will overlap the 'd' when being placed
between a and d. That's probably because it has a width of two pixels.

It also happens within single line text fields, where the caret has a width of
one pixels, but for less characters.

I thought this is one of the smaller ones that will get fixed very soon, but
it's still there and even though it's a minor bug, it can sometimes make filing
out forms really annoying.
*** Bug 114766 has been marked as a duplicate of this bug. ***
*** Bug 131922 has been marked as a duplicate of this bug. ***
*** Bug 132296 has been marked as a duplicate of this bug. ***
nominating EDITORBASE...this is already marked nsbeta1+
Whiteboard: [caret][QAHP] → [caret][QAHP] EDITORBASE
I won't have time for this.

We know why it happens; because we push the caret back into the frame to avoid
drawing turds. To fix this, we need to make sure that the caret can draw outside
of frames without leaving turds (which would be a good thing to fix in general)
Assignee: sfraser → kin
Keywords: nsbeta1+nsbeta1-
Whiteboard: [caret][QAHP] EDITORBASE → [caret][QAHP] EDITORBASE-
EDITORBASE-, marking nsbeta1- per kmcclusk triage
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 145248 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Target Milestone: mozilla1.0.1 → Future
In Windows 2000, modern theme, the caret is one pixel wide and doesn't seem
to obscure any characters to the left or right of it.
On my PC (Win98) the caret in the URL bar is also only one pixel wide and it
still overlaps into the letters (either the one before or the one after it).
It's only two pixels wide in a text box like the one I'm entering this text
right now and the error happens on my PC regardless of theme. It's rather the
font, font-style and font-size used that has an influence on this problem.
This is very dependent on the font used, and where the caret is. It needs toobe
at the end of a frame to show the problem.
*** Bug 168071 has been marked as a duplicate of this bug. ***
Keywords: topembed
topembed+, kin are you the right owner for this? Is there a particular test case
we should be looking at?
Target Milestone: Future → mozilla1.4alpha
leaving topembed+, but I realize this is difficult and should be prioritized
behind most other topembed+ bugs. In other words, something we do want to fix
eventually.
Keywords: topembedtopembed+
Keywords: polish
QA Contact: sujay → beppe
Whiteboard: [caret][QAHP] EDITORBASE- → [caret][QAHP] EDITORBASE edt_x3
EDITORBASE+
Whiteboard: [caret][QAHP] EDITORBASE edt_x3 → [caret][QAHP] EDITORBASE+ edt_x3
using a current mozilla build, look at the attached test case. In the browser
window, set the caret within the textareas and look at how the caret overwrites
the characters, especially the w, m and t.

Now select to edit the page and set the caret within the paragraph, the same
overwrite occurs within the string.

In either case, the caret placement is consistent.
Attached file test case
test case that can be used
Keywords: testcase
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
is this still on track for 1.5a?
*** Bug 196748 has been marked as a duplicate of this bug. ***
Kin, will start working on this starting tomorrow.
Attached patch Patch Rev 1 (obsolete) — Splinter Review
This patch makes things look a bit better. The caret will no longer overlap the
last character on the line *unless* the last character on the line is right up
against the edge of the content area, and there is no padding/margin between
the last character and the edge of the content area.
I should also mention that I tested this patch with text widgets that were LTR
(right and left aligned) and RTL (right and left aligned), and also composer.
Attachment #124856 - Flags: superreview?(sfraser)
Attachment #124856 - Flags: review?(smontagu)
Attachment #124856 - Flags: superreview?(sfraser)
Attachment #124856 - Flags: review?(smontagu)
Attachment #124856 - Attachment is obsolete: true
Attached patch Patch Rev 1.1Splinter Review
After talking to smontagu on IRC we decided to also handle the case where the
caret disappears when indenting a blank doc multiple times past the edge of the
view port  in Composer ... removing the checks for right alignment allows us to
handle that case too.

For reviewers: I am aware of the fact that I do the same calculation in both
cases, but I thought that was ok for the sake of readability.
Attachment #125032 - Flags: superreview?(sfraser)
Attachment #125032 - Flags: review?(smontagu)
I should also mention that with the patch, I was surprised that we don't get any
caret cruft like we used to. This may be due to some of the tweaking that's been
going on over the last couple of milestones to reduce the number of times the
caret draws, etc.

In any case, I've tried this patch out on Win32 and  MacOSX ... and the only
caret cruft that I noticed was only reproduceable in MacOSX builds, and I could
reproduce them without my fix so they are unrelated.
Comment on attachment 125032 [details] [diff] [review]
Patch Rev 1.1

I like it. Much, much simpler, and it works.

One nit:

>+      if (caretRect.x == frameRect.x && caretRect.x <= clipXMost &&
>+          caretXMost > clipXMost)

Please either put all the conditions on the same line or each one on a separate
line.

and one super-nit: why do you say the <br> is "about" 1 twip in width?

I don't think having two conditions producing the same result improves
readability , and the idea I suggested on IRC of combining the two conditions
and interleaving with comments ends up looking even worse. I think my own
preference would be for

  PRBool foo = <expr>;
  /* Comment block */

  PRBool bar = <expr>;
  /* Comment block */

  if (foo || bar)
  {
    caretRect.x = clipXMost - caretRect.width;
  }

The disadvantage of that is that you are evaluating both expressions
unnecessarily. Making each expression a #define would be a way round that, but
is still a bit ugly.

The bottom line is it's up to you :-) r=smontagu whatever you decide.
Attachment #125032 - Flags: review?(smontagu) → review+
Blocks: 141809
Attachment #125032 - Flags: superreview?(sfraser) → superreview+
Target Milestone: mozilla1.5alpha → mozilla1.5beta
*** Bug 211635 has been marked as a duplicate of this bug. ***
*** Bug 136679 has been marked as a duplicate of this bug. ***
as it wasn't mentioned above, the bug shows up in firebird and thunderbird too.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030810 Mozilla
Firebird/0.6.1+
Another duplicate of this bug found at
http://bugzilla.mozilla.org/show_bug.cgi?id=150233
*** Bug 150233 has been marked as a duplicate of this bug. ***
as the patch has a review and a superreview and the target is still set to
1.5beta, are there any chances to get an approval for it?
Attached image Example
Comment on attachment 130469 [details]
Example

Example of the caret overlap bug.  The last letter is an "f".  Note how the
caret overlaps it making typing "annoying".
Attachment #130469 - Attachment description: screen capture of the caret overlap. The last letter is an "f". Note how the caret overlaps it making typing "annoying". → Example
A new target milestone needs to be set.

Current target is 1.5 beta, but 1.5 final will arrive in a few days.
Maybe 1.6 alpha as a new target?
looks like this patch has an r and an sr and we just need someone to drive it
into the tree, yes? I can help with that if I'm reading things correctly.
your help would be highly appreciated. I, too, can't see any reason in this
thread that would prevent this patch from being checked in. Maybe this bug was
just forgotten.

the final patch (rev. 1.1) is from 2003-06-05, that was three month ago. the bug
was filed on 2001-09-06, so it is a really ancient bug.there is a r and a sr but
nobody bothered to check it in up to now.

it is a really nasty bug, because it is so obvious, especially in the mail
client, because here it comes to "heavy typing".
I don't really want to spam bugzilla, but...

Scott, didn't you succeed in driving the patch into the tree? Or, what keeps you
from doing so?

And why could nobody answer my former questions? I'm not annoyed by the fact
that the patch isn't checked in yet, but the fact that no reasons are given for it.
Setting blocking1.6b? hoping to get some attention.
Flags: blocking1.6b?
Good news for all those people that want this bug to be fixed. MadmanNova
includes the revied and superrevied patch in his current Firebird builds
(MadmanNova is known to include MNG support there as well, so his builds show
what MozillaFirebird can be). 

the thread: http://forums.mozillazine.org/viewtopic.php?p=264972#264972

link to a current build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.6b) Gecko/20031116 Firebird/0.7+ (18hr - Mike Tigas (Nova);
MNG,DOMi,Venkman; OxG6;)):
http://www.missouri.edu/~msa0288/MozillaBuild/MozillaFirebird-MNG-DOMi-Venkman.exe
Folks, sorry for the delay in getting this checked in. It fell off the radar. 

I just checked this in tonight. It will be in Mozilla 1.5beta and the next
Thunderbird release.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This bug is also in Thunderbird.  Does this bug report cover that or is a
separate report required, and if so, will this fix also resolve the bug in
Thunderbird?
core bug fixes always fix both. Thunderbird is built from the same tree as
mozilla mail. 
Looks like this bug caused a regression:

http://bugzilla.mozilla.org/show_bug.cgi?id=226325
this was backed out of 1.6b because of the regression it caused in: Bug #226325
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Even when the patch worked, it wasn't all that great. I think the cursor should
just look exactly like it does in a text box (input type="text"). That cursor is
much thinner and also well-placed.
No, not this bug again.

Beside the non collapsing dropdown list, this is the most noticable and annoying
mozilla bug ever!!! I can't believe that the regression mentioned above is that
noticable, because I never noticed it myself. Now it's there in thunderbird and
firebird again. *sigh* I have waited for this fix for years and now...
ok, for all those firebird users that hate this bug as much as I do:

Kindly enough Mike Tigas (MadmanNova) bundles his alternative Firebird MNG
nightlies with the caret patch (rev. 1.1) again.

Please note, that the mentioned patch causes a regression (which will show up
only in rare real life situations, whereas the original problem shows up all the
time -  just my humble opinion ;) ), but it should do its work until a bugfixed
patch is written.

See the specific thread:
http://forums.mozillazine.org/viewtopic.php?t=36797&start=45

Download here: http://www.missouri.edu/~msa0288/MozillaBuild/
Flags: blocking1.6?
Unfortunately, the patch in MadmanNova's build only "solves" the problem in the 
browser and not in the mail client, which is where it is most visible.  Is 
there a patched version of Thunderbird out there?  Is there any update on when 
this "might" be fixed for good?  This is the most annoying bug.
Flags: blocking1.6? → blocking1.6-
Blocks: m6
*** Bug 229304 has been marked as a duplicate of this bug. ***
@ Edward Maloney:

The patch was checked into the trunk for some days. I kept one of the
thunderbird builds from these days (20031126 actually), that worked fine for me
(in any aspect).

I hope, that kinmoz@netscape.com succeeds in updating the patch again, so it can
checked into the trunk again. Maybe just a simple additional check is needed...
*** Bug 238629 has been marked as a duplicate of this bug. ***
Flags: blocking1.7?
Flags: blocking1.7?
Flags: blocking1.7-
Flags: blocking1.6-
Help.

As this bug has been annoying me a lot for quite some time, I started creating
firefox builds for myself and manually merging this patch into the source code.
It all worked fine until May 12th when I successfully created a Firefox build
the last time (available here:
http://forums.mozillazine.org/viewtopic.php?t=71859 ).

But I tried again 2 times ago, it compiled but completely messed up the firefox
layout (the thunderbird one, too). Some icons were just garbage, and the text in
the url and google bar didn't fit. 

Does any have an assumption, what checkin (between May 12th and 30th) can have
caused this behaviour? Many thanks in advance.
Attached image Obsolete (obsolete) —
I attached a picture of the garbage, that shows up when applying the modified
nsCaret.cpp to the source now. Note that even the page rendering is messed up.
Not much to add here because I'm not a programmer, but as a user, I absolutely 
cannot believe that this bug, common to each and every Mozilla product, still 
has yet to be fixed since the summer of 2000.

What do user have to do to help move this up the priority list?  It's one of 
the most annoying bugs and it's been around for far too long. Being common to 
each Mozilla product, I'm really surprised that it hasn't been fixed yet.
Not much to add here because I'm not a programmer, but as a user, I absolutely 
cannot believe that this bug, common to each and every Mozilla product, still 
has yet to be fixed since the summer of 2000.

What do user have to do to help move this up the priority list?  It's one of 
the most annoying bugs and it's been around for far too long. Being common to 
each Mozilla product, I'm really surprised that it hasn't been fixed yet.
Anyone here who can help? (see comment #58/#59). I am sure that I have to
exchange one file with an older revision. Which updated file may cause the
layout garbage?
Comment on attachment 149791 [details]
Obsolete

The garbage was NOT caused by application of this patch. But I didn't figure
that out :(


Sorry for spamming this thread.
Attachment #149791 - Attachment is obsolete: true
Comment on attachment 149791 [details]
Obsolete

The garbage was NOT caused by application of this patch. But I didn't figure
that out :(


Sorry for spamming this thread.
Attachment #149791 - Attachment description: Picture that shows the garbage when applying Rev. 1.1 now. → Obsolete
This bug is now appearing in Firefox 0.9.  

See comments thread Bug#: 238629 

I thought that because the resolution box indicated that the bug was resolved
that it actually was.  I guess it has not been resolved.  
WHEN WILL THIS BUG FINALLY BE FIXED????
If i would be a c-programmer, i'd do it, but please, it's a killer for some of
my customers to switch from Bill's products to Mozilla's...

Maybe advertise to vote for this bug in the mozillazine forums.

I regularily build Win32 builds with the Patch (rev. 1.1) manually applied. I
know that this will introduce the regression, but in my eyes it is better to
have a regression sometimes than a bug always.

Get my builds at pryan.org: http://www.pryan.org/mozilla/firefox/amano/
Will this bug ever be fixed? I want to use ThunderBird but can not just because 
of this bug. I am a visual typist, i.e., I need to see what I am typing to get 
my feedback and this bug disallows me to do that. I really want to get rid of 
O.E. as my mail client and adopt ThunderBird.
Please do something about it.
over hill, over dale, we will hit the dusty trail...

all the editor:core folks are off doing other stuff, folks.  such is the nature
of layoffs.
@ Joe Francis
looks like the got lost on the dusty trail with this one... ;-)

PS: i'm aware that the developer have other things to do too where they get payed.
And yet, since 2001 ... ;-)
Maybe one should change the target milestone in this bug from mozilla 1.5beta to
1.7.2-and-a-half?!

Not aiming to spam this bug, just to reactivate attention on it.... 
happy 'puting


(In reply to comment #70)

> Not aiming to spam this bug, just to reactivate attention on it.... 
> happy 'puting

It's driving me nuts too - the one thing that's stopping me making the switch
from OE to Thunderbird, and still very annoying in Firefox.
*** Bug 258268 has been marked as a duplicate of this bug. ***
(In reply to comment #71)
yeah, it must be really a verrrry difficult task, to add 1 (in words one) to the
positioning counter for the caret at the right place in the right module.
we assume x as the positioning pointer for the caret: 
x = x + 1, or in good old c: x++.

Hmmm... else, since i'm an old fashioned programmer (assembler, cobol on OS390),
knowing nothing about object oriented and all that fancy stuff: if modern
programming is that complex, then i don't know, how it's gonne be in 10
years.... ;-) I guess, we ought to be just lucky to get displayed something on
the screen.... ;-)))
No offense, just a bit humor, ok?!
So there isn't any solution of this problem, that have annoying people since
2000! :) 

Well, I've noticed that the caret is 2px wide in a textbox i.e, but not in the
URL bar. So, I wonder if there is any way that I can change the caret to 1px
overall in the browser? A value in about:config or something?

I use Firefox 0.9.3.
Setting the blocking Firefox 1.0 flag since this is the last remaining highly
visible glitch in Firefox (after having the non collapsing URL bar fixed).

Reasons:
- High visibility (you see it every time)
- Low usability (sometimes it is hard to disinguish if letters have been pressed
or not and sometimes you might confuse letters with others)
- The last issue that lets you easily distinguish between chrome windows and
"true" windows.
Flags: blocking-aviary1.0?
Note that this bug is common to the Mozilla suite, Firefox and Thunderbird.  
Resolving it within one program should be checked to see if it resolves the 
issue on the others at the same time.
we would need a well tested patch at this point to consider for 1.0.  if one
appears please renominate.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Out of curiosity I compiled a thunderbird with the changes of patch rev. 1.0
applied. The regression happened here as well (rather worse, but maybe that's my
imagination). From this I can conclude that only one of those code lines will
cause the regression, that both patch revisions have in common.

Maybe this bug is in need of a new bug owner, since kinmoz@netscape.net didn't
reply to any subjects in this bugzilla thread since June 2003. Maybe this should
be assigned to smontagu@smontagu.org since he had a look at this stuff already.
To push Firefox and Thunderbird in the internet is one thing (which i totally
support), to fix such an obvious and obnoxious bug is a total different thing
and should be done, NOW!
Hey, you, who is in charge of this, wake up!!!
People considering of switching away from IE want to see a clean product, not
only inside, where they can't see, but also on the outside, where they can see!
Lukas Wymann, before commenting on bugs, please read
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Thanks,

Prog.
(In reply to comment #80)
> Lukas Wymann, before commenting on bugs, please read
> http://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> 
> Thanks,
> 
> Prog.

Oh, how good, that some people know at least how to behave unlike me.
And others don't know how to fix bugs, unfortunately, since ... ehhmmm, when was
this opened? Sometimes in the year 2001 with first comments already a year before?!
I'm sorry, but you're targeting the wrong guy with this link!

Well, I applied patch "Patch Rev 1.1" to my trunnk (1.8a) debug build.
I couldn't reproduce bug 226325 after that with the testcase attached in that bug.
Then I backed out the patch for bug 216101 and after that I could reproduce bug
226325.
Depends on: 226325
Rescued from the mailbox that catches our bounces:
(for future reference, you need to click the link at the top of the bugmail, and
add your comment using the form on the web page)

Date: Wed, 27 Oct 2004 14:47:00 +0200
From: dumbone <dumbone@greenmail.ch>
To: bugzilla-daemon@mozilla.org
Subject: Re: [Bug 98564] caret overlaps the last character in textfield (if
positioned after the last char)

>Well, I applied patch "Patch Rev 1.1" to my trunnk (1.8a) debug build.
>I couldn't reproduce bug 226325 after that with the testcase attached in that bug.
>Then I backed out the patch for bug 216101 and after that I could reproduce bug
>226325.

Hi
Thanks for the suggestion. Did you test also the regression-bug, leaving
a drawn caret to the right of the newly blinking caret, when you
backspace at the wrong moment?
Regards,
and Thanks,
Lukas
(In reply to comment #83)
> Thanks for the suggestion. Did you test also the regression-bug, leaving
> a drawn caret to the right of the newly blinking caret, when you
> backspace at the wrong moment?
Well, that's what I meant with bug 226325 (the regression-bug). Or is there
another regression that was caused by fixing this bug?

Hurray. Wonders happen ;)

TEST BUILD: I manually applied the patch for bug 216101 to the current Fx RC2
sourcecode and everything works well. The garbled stuff when pressing backwards
can't be seen anymore. A test compile to see how well it works can be found here:

http://www.pryan.org/mozilla/firefox/amano/Fx-1.0RC2-O1-Gopher-MNG-Exp.exe

BRANCH APPROVAL: I know, that it is late in the game, but since chofman
explicitly asked to renominate this bug for 1.0 when a patch appeared I do so
(especially since this is a highly visible bug, common to all Mozilla products
for ages). To solve this bug a branch checkin of the patch for bug 216101 (
https://bugzilla.mozilla.org/attachment.cgi?id=151657&action=view ) would be
needed as well (both patches have a review and a superreview).

TRUNK checkin/Thunderbird: @Scott McGregor: Can you help again to check this
into the trunk. Since the fix for bug 216101 landed on the trunk already, it
should work like a charm now. Since thunderbird is more affected by this bug,
you might want to land both patches (
https://bugzilla.mozilla.org/attachment.cgi?id=125032&action=view and
https://bugzilla.mozilla.org/attachment.cgi?id=151657&action=view ) on the
branch for Thunderbird 1.0 as well.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
(In reply to comment #85)
> Hurray. Wonders happen ;)
> 
Ditto!
As far as my testings with this build from Bernd and my eyes go, it seems to me
that it got solved; the overlap-issue and the regression as well.
THANK YOU THANK YOU THANK YOU ! :-)
ok guys. I need help testing this on the aviary 1.0 thunderbird builds. I just
put both patches there and could really use testing coverage for caret regressions! 

I also just checked this fix back into the trunk (*again*) since it looks like
216101 fixes the caret fragment regressions this patch introduces.
Status: REOPENED → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → FIXED
Keywords: fixed-aviary1.0
in TB version 0.9+ (20041110) looks ok everywhere expect the actually message
body when typing a new email or replying to an email. In the search bar, subject
bar and address bar the caret is fine, only the message body the caret is still
fat and overlapping
(In reply to comment #88)
> in TB version 0.9+ (20041110) looks ok everywhere expect the actually message
> body when typing a new email or replying to an email. In the search bar, subject
> bar and address bar the caret is fine, only the message body the caret is still
> fat and overlapping
I think that's basically bug 261054 (that one was fixed on trunk).

Well. *sigh* 

There is actually still a small regression.
It happens only in the compose text field, not in firefox, not in the
thinderbird search or address fields, since they use a different default font.

The problem is that with the patch applied only the stuff on the left side of
the caret is deleted. For certain letters (above all the "f"s and "/"s) in
certain fonts (especially italic fonts and "Gigi") one part of the letter
overlaps the caret and therefore isn't deleted when pushing back. That leads to
some garbage (eg when typing "ffffffffffffffffffffff" and then deleting it).

I cc'ed AARON LEVENTHAL (aaronleventhal@moonset.net) since he is the only one
that had a look into nsCaret.cpp for a very long time. Maybe Aaron can come up
with a quick fix for this problem. 

Anyway I cannot suggest to back out the patch again since the regression (which
is left) is minor and the garbage doesn't happen under real world usage (who
types "fffffffffffffff") and doesn't show up with Firefox at all while the
problem that is fixed by this patch shows up everytime. But Scott will have to
decide.

Maybe we should leave the patch on the trunk and file a separate bug to get some
movement with this problem while Scott decides what to do with this on the branch.
I think the problem mentioned in comment 90, is in fact bug 197129. So that is
not a regression from the fix from this bug. I can see the problem mentioned in
comment 90 also with Mozilla1.7 Mail from 2004-06-16.
This bug now shows as RESOLVED and FIXED.  When is the fix being released? I've 
been watching this one now for over 2 years and it annoys me that it's still 
there.
How is this bug fixed? A bug is fixed, if the code is in the trunk and I can
download a nightly where this bug is not shown any longer. So far I have not
seen any such nightly, hence there is no reason to mark this bug as fixed! The
latest nightly I can use on windows still shows the bug and the very latest
nightly is unusable.
I can fonfirm that this trunk build contains the fix:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041204
Firefox/1.0+

It is fixed on the branch as well, just test the release candidate of
Thunderbird 1.0.

BTW, Martijn Wargers seems to be right in comment #91. This comes from heavy
caret testing. You stumble over other bugs ;)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: