Closed Bug 80048 Opened 23 years ago Closed 23 years ago

First letter not selectable in textbox if particular letter

Categories

(Core :: DOM: Selection, defect, P2)

Product:
Core
Component:
DOM: Selection
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: wd, Assigned: mjudge)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [select] FIX IN HAND needs r= and a=) 

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
Keywords: regression
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
Severity: normal → major
Priority: P3 → P2
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.
OS: Windows ME → All
*** 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. ***
Keywords: nsCatFood
*** Bug 81483 has been marked as a duplicate of this bug. ***
*** Bug 81621 has been marked as a duplicate of this bug. ***
Whiteboard: [select]
this MIGHT be fixed with a patch  i made for 68641.give it a shot...
Status: NEW → ASSIGNED
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.
Keywords: nsbeta1
*** 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;
Whiteboard: [select] → [select] FIX IN HAND needs r= and a=
add simon since it is his code
r=ftang
a= asa@mozilla.org for checkin to 0.9.1
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
merking verf :-) win 05-25-20 build
Status: RESOLVED → VERIFIED
*** Bug 83035 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.