Build ID: 2001050915 When text is in a textbox, the first letter is impossible to select if it is one of the following: b c f g j k n o r s v w z Reproducible: Always Steps to reproduce: 1. Go to http://www.google.com 2. Type in something which begins with one of the above letters 3. Select the text with the mouse Actual results: The first letter is not selected Expected results: all characters are selected

win98, 2001-05-09-17-trunk. Doubleclicking or context menu select all works, drag-selecting doesn't. Additional characters: 2 3 6 7 § " # & / ? + £ { [ ~ ^ * ' ö ë > _ : . ;

I can reproduce this on win98, Kin was unable to reproduce this on winNT using a debug build from today. A very reduced testcase fro you: this is a test <form action="fred.html" method=post> <input type=text size=20 max=18 name=test value="sujay@netscape.com"><br> <input type=text size=20 max=18 name=test> </form> 1. copy the code to a file 2. when displayed in browser window, highlight the content of the first textfield, the "s" will not get highlighted

using todays opt build 2001051104 on winNT, I cannot reproduce this bug, I will verify this on yesterdays build on win98

FWIW, I see this with 2001051104 on WinMe

this problem exists on the 2001051004 build and the 2001050915 build, still trying to figure out when this got introduced

ok, it got broken somewhere between the 2001-05-08-22-trunk build and the 2001-05-09-06-trunk build. On that day, there was a boat load of checkins: http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=MozillaTinderboxAll&date =explicit&mindate=989309280 http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=MozillaTinderboxAll&date =explicit&mindate=989395380

I believe the bug is more general than reported. When I try to select any chunk of text rendered in the browser (not just in a text box, but anywhere in the browser), I cannot select the first letter if the letter is in the set [b c f g j k n o r s v w z], case insensitive. I see this on Win95, Build ID: 2001050915. Test case: try selecting various bits of text on this page, both in text boxes and elsewhere.

Selection is not required; just go anywhere in a textbox and press "home". (You cannot point the caret into the beginning of the textbox with the mouse either.) First character of any line on a textbox behaves similarly. Actually the problem character needs not be a first character (or in a textbox as Dave pointed out) either. Just highlight backwards any text in browser; other characters are highlighted when cursor is halfway over them, but the mentioned characters need to be completely run over. Highlighting forward, the odd characters are highlighted earlier than others.

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

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

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

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

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

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

this MIGHT be fixed with a patch i made for 68641.give it a shot...

Is this really OS:All? I'm not seeing on Mac or Linux.

Does anyone else think this should be nominated for nsbeta1? This kind of bug is visible enough that letting it slip into a public release might be a tad embarrassing...

I know this is driving ME nuts. This can be reproduced in the URL bar too, which makes it maddening if like me, you make heavy use of ftp: and file: urls. This bug can also be reproduced in the To: and Subject: boxes in mailnews compose (but not, it seems, in the message body)

Adding the nsbeta1 request keyword.

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

on win98/me i call acx->GetWidth(char,returnwidth); and it sometimes (for the letters in question above) return a negative number... like in fixed width all letters return 120. but the 's' and say 'W' letters return -120. what the hell is going on here. i see no rhyme or reason to this maddness. I am going to look at renderingcontext::getwidth next. something is totaly hoarked.

ok fixed it. no one initialized parameter nor did they check return value. here is patch Index: nsRenderingContextWin.cpp =================================================================== RCS file: /cvsroot/mozilla/gfx/src/windows/nsRenderingContextWin.cpp,v retrieving revision 3.129 diff -u -r3.129 nsRenderingContextWin.cpp --- nsRenderingContextWin.cpp 2001/04/11 23:02:31 3.129 +++ nsRenderingContextWin.cpp 2001/05/25 23:01:14 @@ -1538,9 +1538,8 @@ PRUnichar buf[1]; buf[0] = ch; #ifdef IBMBIDI - WORD charType; - ::GetStringTypeW(CT_CTYPE3, &ch, 1, &charType); - if ((charType & C3_DIACRITIC) && !(charType & C3_ALPHA)) { + WORD charType=0; + if (::GetStringTypeW(CT_CTYPE3, &ch, 1, &charType) && (charType & C3_DIACRITIC) && !(charType & C3_ALPHA)) { // aWidth = 0; GetWidth(buf, 1, aWidth, aFontID); aWidth *=-1;

add simon since it is his code

r=ftang

a= asa@mozilla.org for checkin to 0.9.1

fixed

merking verf :-) win 05-25-20 build

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