128394 - Cursor position widely off from actual text when selection is made.

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P2)

Description

[hirata masakazu]

2002022508 trunk for MacOS9.x
In mail or news messages, text selection by click and drag shows that the cursor
position is far left to the point where the actual text being selected is. The
cursor position matches with the text only at the beginning of the line. This
happens with  single-byte text, but not with 2-byte text. 
If the text is encoded in iso-20022-JP, even the single-byte text is selected
correctly without wrong cursor position.
For example, if you first place the cursor at the beginning of the line and
start selecting toward the end of the line, the actual selection reaches the end
of the line by the time your corsor position has proceeded to 80 to 90%.

Comment 1

[nhottanscp]

Is this about mail composer or message view?

>This happens with  single-byte text, but not with 2-byte text. 
>If the text is encoded in iso-20022-JP, even the single-byte text is selected
>correctly without wrong cursor position.
Does this mean problem if "us-ascii" or "ISO-8859-1"?

Comment 2

[hirata masakazu]

I am seeing this in message view only. Composer window is not affected.
Both ISO-8899-1 and us-ascii show this bug.

Comment 3

[nhottanscp]

Then probably this is not international bug. Need more info.
Are you using Japanese MacOS 9?
Do you see the problem for both html and plain text mail?
What fonts do you set for Western language?

Comment 4

[hirata masakazu]

I do not have a good example for HTML mail now, but I suppose it does not happen
since
browser window is OK including textarea of forms, though I see some problem with
URL bar(separate bug, I guess).
I have tested OSX10.1.3, and it happens the same way as OS9(Japanese).
For Western monospace fonts, I tested Courier, Courier New, and Monaco. They all
showed this
bug.  When I changed the font for mono-space to Helvetica, the error became
reversed: this time, selection laged the cursor in rightward movement, and the
selection was ahead in leftwardmovement. 

Comment 5

[nhottanscp]

How about plain text file in browser? Do you also see the problem?
I actually cannot reproduce the problem (with us-ascii plain text mail like
bugzilla bug) on MacOS X. Do I need to set the default language to Japanese?

Comment 6

[hirata masakazu]

I have default language for viewing mail/news set as Western ISO-8859-1.
Is the text in this bugzilla form a plain text in your context? If so, I see no
problem with plain texts in Browser window.

Comment 7

[nhottanscp]

>Do I need to set the default language to Japanese?
This, I meant for the language of MacOS X.
>with us-ascii plain text mail like bugzilla bug
This was a mistake, I meant for reading bugzilla mails in the mail client. I
don't see the selection problem.

Comment 8

[hirata masakazu]

I do not know how to change the default language in OSX, but mine is Japanese
version, I suppose.
Due to e-mail address change, I do not receive the bugzilla mails. But I have
several plain text mails in us-ascii and iso-8859-1 in addition to mozilla news
group messages which all show this problem.
I have just downloaded 0304 build for MacOS9.x, and it still shows this bug. I
am sure this is relatively new, (probably started around 20020220 build), since
it does not happen in 20011206 trunk build which I sometimes use as a reference.

Comment 9

[nhottanscp]

I used today's commercial trunk but cannot see the problem.
I tried the newsgroup netscape.public.mozilla.macosx.
My font for western is helvetica 16 and courier 13.
Used OS X 10.1.3, I set my system default to Japanese (by using the system
preference).

Comment 10

[hirata masakazu]

Then, this may be a Mozilla-only problem. 2002030508 trunk Fizilla is still
affected.
Another way to demonstrate this problem is double clicking on a word in a line,
which should select the word. If this bug is present, double clicking on a word
at the beginning of a line selects the word correctly. However, when you try it
on a word near the end of a long line, the selection is made for the next
word.(BTW this is for fixed-width font)

Comment 11

[nhottanscp]

Cc to marina, ylong, I need IQA help for this.

Comment 12

[Yuying Long]

I checked it on 03-06 trunk build/Mac OS X and 02-28 build build / Mac9.1-JA:
1. Mac9.1-JA & Mac OS 10.1.3 with JA default locale:
   When charset set to iso-2022-jp will work fine, and when charset set to
western or Chinese then will see the problem.
2. Mac OS 10.1.3 with US locale:
   When charset is marked as western, it works fine, but when I set to
iso-2022-JP or other double byte charset then will see the problem.

Seems like if we use charsets that not followed the OS locale, then will has the
problem.

Comment 13

[Frank Tang]

Is this a regression?
does this only happen in plain text ?
nsbeta1+
reassign to ftang

Comment 14

[Frank Tang]

assign

Comment 15

[Frank Tang]

I cannot reproduce this issue. need help from ylong.

Comment 16

[nhottanscp]

Attachment: HTML using lang attribut, has the cursor problem

Comment 17

[nhottanscp]

Attachment: ignore the last one, I submitted as plain

Comment 18

[nhottanscp]

The problem is related to the 'lang' attribute used for mail view.
The selection is wrong when 'lang' is specified.

Comment 19

[Frank Tang]

P2. nhotta- which fix cause this regression ?

Comment 20

[nhottanscp]

Immediate cause was by bug 102623 which changed to specify lang for the message
display. But there is a generic selection problem with lang attribute specified
because it is reproducible by browser (using the attachment #73320 [details]). NS6.2 does
not have the selection problem with the attachment.

Comment 21

[Frank Tang]

reassign to shanjian

Comment 22

[hirata masakazu]

There is another text selection problem caused by an attribute, align="justify".
(Bug 11682.)

Comment 23

[Shanjian Li]

Attachment: patch

Comment 24

[Shanjian Li]

Attachment: a simplified testcase

Comment 25

[Shanjian Li]

As shown in the simplified testcase, we failed to utilize langGroup 
info when prepare font for locating cursor position within text frame. 
My patch correct this. I thought about change the definition of 
nsIPresContext::GetMetricsFor. There are 2 reasons that makes me not 
do so. First, there are many reference to this method, so extensive 
changes need to be made. Second, almost all the calls except the one 
I modified are used to render things like bullet, br, and so on. They 
don't really care about langGroup.  

Comment 26

[Shanjian Li]

rbs, could you review my patch?

Comment 27

[rbs]

Comment on attachment 76424 [details] [diff] [review]
patch

r=rbs

>Use nsCOMPtr
+      nsIFontMetrics* fm;
[...]
+      NS_IF_RELEASE(fm);

Comment 28

[Shanjian Li]

rbs, nsIDeviceContext::GetMetricsFor takes nsIFontMetrics*& instead of 
nsIFontMetrics**, and add_ref is done inside GetMetricsFor. That's why 
I did not use nsCOMPtr. 

Comment 29

[rbs]

->
    nsCOMPtr<nsIFontMetrics> fm;
    deviceContext->GetMetricsFor(font->mFont, langGroup, *getter_AddRefs(fm));

Comment 30

[Shanjian Li]

Attachment: update patch

Comment 31

[Shanjian Li]

Marc, could you sr?

Comment 32

[Marc Attinasi]

Comment on attachment 76451 [details] [diff] [review]
update patch

sr=attinasi (you might want to check for |visibility| not being null before you
check for |visibility->mLanguage| though)

Comment 33

[Asa Dotzler [:asa]]

Comment on attachment 76451 [details] [diff] [review]
update patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 34

[Frank Tang]

Impact Summery
Impact Platform: ALL
Impact language users: 650M 100%
Probability of hitting the problem: HIGH, selection in all the mail messages and
some web page have this problem
Severity if hit the problem in the worst case: Selection is totaly off, it will
be very difficult for user to perform select&cut/copy action.
Way of recover after hit the problem: None
Risk of the fix: MID
Potential benefit of fix this problem: Other display problems?
regression, suggest adt1

Comment 35

[Frank Tang]

adt1.0.0
high impact bug 
please test against mail viewing.

Comment 36

[Shanjian Li]

Tested with mail, I could not see any problem after the patch. 

Comment 37

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for checkin into 1.0, but pls test it on all
platforms before we check it in.

Comment 38

[Shanjian Li]

I verified my patch on Linux. It works as expected. 

Comment 39

[nhottanscp]

I tested (attachments id=73320, id=76425) on MacOS X with the patch I did not
see the selection problem.
Does the patch affects for viewing only? No editor testing is needed?

Comment 40

[Shanjian Li]

Yes, this patch only affect display. If there is problem in editor, that will be 
a different issue. 

Comment 41

[Shanjian Li]

fix checked in. 

Comment 42

[ji]

Verified as fixed.

Comment 43

[red]

I did not see this problem in Mozilla 1.21 for OS X. Running 1.3b, all of a
sudden it shows up.