204434 - [1.4 branch only] JA IME: cursor position is off before and after text is committed

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Katsuhiko Momoi]

** Observed with 2003-04-29 trunk build **

When you input Japanese characters, the cursor position is incorrect in that 
it is slightly left of the end of the character in question. This is a critical
regression and should be fixed before any formal release.
It makes it very difficult to input Japanese character since the cursor 
position does not does not give feedback on the correct insertion 
point. This problem exists only under the candidate mode. When the text is
committed or when you wait long enough, the cursor position corrects itself.

I emphasize this point: This is not acceptable behvaior in
Japanese Input process.

Comment 1

[Yuying Long]

On 05-01 trunk build / WinXP-JA, I don't see the cursor "slightly left of the
end of the character".  But I see the cursor at the beginning of the string.
(bug 204491)

Which WinXP do you have?

Comment 2

[Katsuhiko Momoi]

I use Winx XP-EN with the locale set to Japanese. 
This sounds like the same probelm with different manifestation. 

Comment 3

[Yuying Long]

OK, I saw this on Momoi-san's computer, and I saw it on my system as well but
not clear as in his machine, I guess it's probably because the mouse or system
setting, my system is faster than his, so on my system, it appear a very short
time so that there is not enough time to notice it.

This is a regression from N7.02, and it's a bad user experience.

Comment 4

[Yuying Long]

This exists on Mac 10.2.5 and linux RH8.0, change platform to All.

Comment 5

[marina]

Frank, should that be reassigned to you?

Comment 6

[bobj]

> This is a regression from N7.02, and it's a bad user experience.
I agree.  Reassigning to ftang.

Comment 7

[bobj]

Frank and Yuying looked at this, but saw something less serious.
Kat, Please demo the problem to Frank, so we understand the problem.

Comment 8

[Teruko Kobayashi]

When you type Japanese consonent, the cursor moves one byte at once. At that
time, the cursor is in the middle of the Japanese character. Then, the cursor
moves at the end of character.  

This is very bad user experience for Japanese users.

Comment 9

[Katsuhiko Momoi]

Let me add to what I and Teruko already said about this problem.
You should not try to **quantify** the severity of this problem.
No legitimate Japanese IME has this type of cursor position in 
candidate mode. To those of us using JA IME on a daily basis, 
this is simply not acceptable. No ifs and buts. It is particualrly
bad because earlier public releases don't have this problem.
(I'll be happy to demo this problem but so can reruko & ylong.) 

Comment 10

[Katsuhiko Momoi]

The problem is not there in Mozilla 1.4a release but
it is in Mozilla 1.4b release. So this problem surfaced
recently.

Comment 11

[Katsuhiko Momoi]

Incorrect cursor position provides incorrect feedback
for Japanese input. Correct cursor position feedback 
is expected in any application meant for Japanese input. 
Anything less is unacceptable.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I can't reproduce with 2003-03-29 WinXP build.
But I can reproduce with 2003-04-03 WinXP build.
(I don't have the between builds)

source code of the caret is changed by bug 35296(checked in 21:48 4/1).

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaBranchTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=03%2F29%2F2003+00%3A00%3A00&maxdate=04%2F03%2F2003+00%3A00%3A00&cvsroot=%2Fcvsroot

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

We have a report.
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3174#c7

he can reproduce with camino.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030402
Chimera/0.7+ ]

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

we have a next report.
he said, he can't reproduce with camino 4/1 build.

this problem is made between 4/1 - 4/2!

Comment 15

[Teruko Kobayashi]

I found that this started to happen from 04-18-04 trunk Win32 build.
This worked fine in 04-17-09 trunk Win32 build.  

In comment, #12
>I can't reproduce with 2003-03-29 WinXP build.
>But I can reproduce with 2003-04-03 WinXP build.

I tested 04-03 Trunk build, but I can't reproduce this with 04-03 Win32 build on
WinXP.  

I tested Netscape builds. 

Comment 16

[Frank Tang]

I think this is not an important bug for the following reason
1. It only happen when the user is using Romaji keyboard layout, if the Japanese
users are using Kana keyboard layout, this problem won't show up at all.
2. It only happen after user type a consonant "k", "s", "g" then press vowel
"a","e","i","o","u"
3. It only happen ONE blink, instead of state this is a "incorrect cursor
position", this is really a "delay of update cursor position of one blink". The
cursor blink in the old (not wrong, but old) position, with exacatlly one blink.
After that blink, the cursor blink in the up-to-dated position.
4. The "wrong" position is not WRONG, but OLD position instead. 
5. It cannot be reproduce in a fast machine. 
6. The cursor won't be able to make user type text in any WRONG position, the
cursor will be draw in the right position BEFORE user are able to change the
cusor position. Actaully, if the user type very fast, they won't even be able to
see the cursor position to be draw in the "old" place. 

Comment 17

[Teruko Kobayashi]

From Frank's comment #16, 

>2. It only happen after user type a consonant "k", "s", "g" then press vowel
"a","e","i","o","u"

This is true, but Japanese has more consonents than vowels. We can see this
frequently.

>5. It cannot be reproduce in a fast machine. 
I see this in a fast machine (2.39GHz). I think the speed of the machine does
not matter. We see this depending on how fast you type.

  

Comment 18

[Katsuhiko Momoi]

In comment #16, Frank Tang says:

> I think this is not an important bug for the following reason

Your reasons are mostly incorrect.

> 1. It only happen when the user is using Romaji keyboard 
> layout, if the Japaneseusers are using Kana keyboard 
> layout, this problem won't show up at all.

**Most** Japanese users use the Romaji input method. You can use this
method even on Kana style keyboard. This is why the problem
is reproduced by several people on the Japanese version of 
this bug at:

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3174

This statement is incorrect in associating the keyboard 
type to type of input method. The main input method used these
days is Romaji input method, not Kana input method. Many
studies show this. For example, read this expalantion (in
Japanese) explaining Romaji Input Mehotd:

http://e-words.jp/w/E383ADE383BCE3839EE5AD97E585A5E58A9B.html

> 2. It only happen after user type a consonant "k", 
> "s", "g" then press vowel "a","e","i","o","u".

This is incorrect, the problem happens after inputting almost
all the consonants. By the way, Japanese has only 5 vowels and
so you listed all the vowels. 

Japanese uses the following consonants in syllable initial 
positions:

k, g, s, z, t, d, n, h, b, m, y, r, w

Plus N (syllabic nasal)

I found that the problem occurs after all the consonant except "m" and
"w". In the case of "m", the cursor position is also incorrect
but it is one character to the right.
So "w" is the only character that does not have a problem of 
some kind.

As it turns out, the above combinations where the problem occurs
is over 95% of the words in Japanese.

> 3. It only happen ONE blink, instead of state this is 
> a "incorrect cursor position", this is really a "delay of 
> update cursor position of one blink".

I don't care what you call it, but this is incorrect feedback and
it affects people's input activities badly and it also presents
bad user experience. Japanese-ready applications are expected
to behave correctly.
 
I simply don't agree with your evaluation as an everyday Japanese
IME user.

> 5. It cannot be reproduce in a fast machine.

Not true. I have a pretty fast machine abotu 2GHz processor
and I see this problem.

> 6. The cursor won't be able to make user type text in any 
> WRONG position,

But it does affect users' input activity very badly when the
feedback is incorrect. This is bad user experience.

======
I don't agree with your assessment of the importance of
this problem in the Japanese market. Don't make a mistake of
assuming that users will not care about this problem. Something
that has to do with character display and display is a BIG
problem for Japanese users if it is not working correctly
like other applications. 

Raising the severity level to critical as this is a very
important problem for Japanese users.

Comment 19

[Katsuhiko Momoi]

I want add 2 more cases of serious nature to what's been reported
already.

1. When the line ends in an ASCII character, e.g. .... Los Angeles (eol),
   if you then try to add one Japanese character after this, you see the
   cursor jump 2-3 characters ahead. Typically, you would add a Japanese
   grammatical particle like "wa", "o" after a noun like this and so this
   is a very common occurrence.

2. When you begin a syllable with the "m-" consonant, the cursor position
   shifts one character to right rather to right as reported earlier.

Note: Let me clarify the problem in case people are having difficulty with
      reproducing this problem. The problem occurs when "conversion" is
      not used but when Hiragana sequence is commited as is. 

Comment 20

[Katsuhiko Momoi]

Adding some people who worked on caret releated bugs recently.

Comment 21

[Katsuhiko Momoi]

The root probelm for this bug seems to be that the cursor position
is somehow remembered for the alphabetic character and when the
wide character is inserted, the position is off by the amount of the
space between that single-byte alphabetic charcter and the Asian character.

This delayed cursor position porblem is observed under 2 conditions 
in Japanese:

1. When the text input is still not commited.
2. After the text input has been committed.

(Note: In Chinese you see this problem under condition #2 only usually.)

#2 is particularly bad because the user is supposed to be moving to the
input for the next word and should not be seeing the cursor moving back
or forward to delay this action.

You can see this problem also in Chinese input methods.
Frank Tang and I experimented with this and this is how you can reporduce
this problem:

1. Choose the keyboard Chinese (PRC).
2. Choose the input method, QuanPin or ShuanPin.
3. Open Composer and input "a" or any other single vowels
   like "i", "u", "e", etc.
4. When the Chinese character selection box comes up, choose
   any character and commit. You can see the cursor usually half character
   to the left of the real position and then move back to the right 
   position.

This affects not only Japanese but also Chinese. In the case of Japanese,
it is particualrly bad affecting the user's ability to input characters
smoothly. This to me is a blocking bug for release in Asia, and particularly
in Japan, where more than 10% of Gecko downbloads occur. Display and Input
are bread and butter functions for browser/mail/composer. This kind of
fundamental problem cannot be ignored. Setting Milestone to 1.4 Final.

Comment 22

[leon.zhang]

I meet a bug when I type chinese word (中)into composer in
windows2000(simplified chinese version), there exist a crash.
stack below:

nsWindow::HandleTextEvent(unsigned long 0x0a18013f, int 0x00000000) line 5715 +
33 bytes
nsWindow::OnIMEComposition(long 0x00000800) line 6101
nsWindow::ProcessMessage(unsigned int 0x0000010f, unsigned int 0x00000000, long
0x00000800, long * 0x0012fc34) line 4327 + 15 bytes
nsWindow::WindowProc(HWND__ * 0x002a0b10, unsigned int 0x0000010f, unsigned int
0x00000000, long 0x00000800) line 1349 + 27 bytes
USER32! 77df2e98()
USER32! 77df30e0()
USER32! 77df320f()
nsAppShellService::Run(nsAppShellService * const 0x015c19a0) line 479
main1(int 0x00000001, char * * 0x002c4ea0, nsISupports * 0x00f0bf60) line 1268 +
32 bytes
main(int 0x00000001, char * * 0x002c4ea0) line 1647 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e77d08()


I think mIMECursorPosition should be initialized in nsWindow::nsWindow().
I will give a simple patch here.
After apply this patch I can type chinese chars into composer.

Comment 23

[leon.zhang]

Attachment: fix crash when type chinese chars into composer

Comment 24

[leon.zhang]

I test this bug in my windows 2000(simplified chinese version), using sevral
input methods including: QuanPin, microsoft's PinYin, ZiGuang.
up to now, I still can not reproduce this bug.

Comment 25

[leon.zhang]

I can reproduce this bug now.
this bug is related to bug 205544.
try the last patch for that bug:
http://bugzilla.mozilla.org/attachment.cgi?id=123850&action=view

Comment 26

[Katsuhiko Momoi]

Asa, if it is my opinion you're seeking, 

Since there will be a commercial release based on 1.4, this bug would be
a blocker for a release in Japan. Possibly in China but I am not
sure as how the Chinese user will see its severity. For Japanese users, this will
be a bread and butter issue -- so fundamental that we can alienate users from
using Mail and Composer. (How would an English user feel if the cursor
behaved erratically while typing? This is what we are facing in Japanese.)

I recommend fixing this before the final release.

Comment 27

[Katsuhiko Momoi]

adding smontagu since he also works on caret position related matters.

To leon: I have not confirmed this but the Japanese version of this 
         bug report has a comment from a Mozilla volunteer that the patch
         you suggested in bug 205544 in comment #25 does NOT fix this
         problem. (I will try your patch later myself.)

          

Comment 28

[leon.zhang]

 Katsuhiko: 
In my testing env, I can only type chinese chars into composer using QuanPin
input method.  when I reproduce this bug, I can only find the caret blink in the
middle pos of chinese char, then jump to the correct pos. 

After using patch in comments #25, the caret's pos is correct.

can you verify it?

Comment 29

[Katsuhiko Momoi]

Leon: I tried your last patch mentioned in comment #25, but that did
      not fix the problem. 

      Next, I tried 4 patches mentioned in the Japanese Bugzilla comment #16. 
      
       http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3174#c16

      The comment is in Japanese but 4 Bugzilla patches with links 
      should be clear to you. These 4 together fix the problem.

      However, there was one thing I did not like, and that is, 
      these patches hide the cursor position while you're typing.
      When the movement stops, that is when the cursor is placed
      at that spot. So, with these patches, it looks like the cursor
      problem does not exist. But the truth may be that because the
      cursor is hidden while typing, the problem might not be visible.
      Is this the correct fix for this problem? I don't know for sure.


      

Comment 30

[Katsuhiko Momoi]

To add to comment #29, it does not seem so bad not to see the caret
when you input Japanese but inputting Latin Alphabet and not see the
caret until you stop typing feels wrong to me. It in fact bothers me a
lot.

Comment 31

[leon.zhang]

Attachment: proposed fix(if new reflow happen, refresh cache)

Comment 32

[leon.zhang]

Attachment: good format

Comment 33

[leon.zhang]

Comment on attachment 124066 [details] [diff] [review]
good format 

Katsuhiko, try this patch.
I cannot type japanese chars , and typing chinese chars is ok here.

Comment 34

[Simon Fraser [no longer active]]

Comment on attachment 124066 [details] [diff] [review]
good format 

Rather than calling SetReflowHappen(), why can't the editor code just call
SetCanCacheFrameOffset(PR_FALSE)?

This seems like just more special-casing to hack around problems with the
cached offset. We can't keep adding hacks to this code; I'd rather just remove
that offset cache altogether.

Comment 35

[Samir Gehani]

adt: nsbeta1+/adt2

Comment 36

[Frank Tang]

I don't think I am the right person to work on this. Reassign to [e-mail]
It looks this is introduced by the cursor performance optimization work and I am
not familar with it. 
after I discuss with momoi, I do agree this is a bad bug and should be fixed by m1.4
Leon: can you fix it ?

Comment 37

[leon.zhang]

Comment on attachment 124066 [details] [diff] [review]
good format 

some guys can help to test this patch? i have not the tesing env. thx

Comment 38

[Katsuhiko Momoi]

Leon, I tried your attachment 124066 [details] [diff] [review] with the latest Mozilla trunk build 
and it resolved all the problems I am aware of in Japanese and Chinese input. 

There is also a report in Japanese Bugzilla about this patch on
Mac with Japanese IME. It is reeported that it also works OK
with Mac trunk builds and Firebird as well.

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3174#c23

I also did not observe the disappearance of the cursor with this fix.
So far the proposed patch looks good. 

To be on the safe side, you should let us know what potential problem
areas there could be and what people should test carefully with this
patch.

Comment 39

[Katsuhiko Momoi]

I tried your patch on Win XP. I've also asked Japanese Mozilla 
developres to test the patch on Linux. Hopefully someone will do
so soon.

Comment 40

[leon.zhang]

Current mozilla is ok when input  english chars(I have tested for long time too).
I did not try the chinese/japanese chars chars when I do some thing related to
perf of editor. The process of typing chinese word is a little different from
normal typing western chars.Because of this bug, I do some things to make the
cache for caret pos more robust. Now, It should be ok according to your testing
result.

Comment 41

[leon.zhang]

when type an chinese/japanese word, we will meet stack below 3 times, and reflow
will happen in the first 2 times:

nsHTMLEditor::SetCompositionString() line 4270
nsTextEditorTextListener::HandleText() line 585 + 53 bytes

nsEventListenerManager::HandleEvent() line 1590 + 41 bytes
nsDocument::HandleDOMEvent() line 3620
nsGenericElement::HandleDOMEvent() line 1961 + 47 bytes
PresShell::HandleEventInternal() line 6387 + 47 bytes
PresShell::HandleEvent() line 6288 + 25 bytes
nsViewManager::HandleEvent() line 2268

--------------------------------------------------------

when type an english char, we will meet stack below once,and reflow will happen
once too:
nsHTMLEditor::TypedText() line 1441
nsHTMLEditor::HandleKeyPress() line 1426 + 34 bytes
nsTextEditorKeyListener::KeyPress() line 298

nsEventListenerManager::HandleEvent() line 1631 + 41 bytes
nsDocument::HandleDOMEvent() line 3620
nsGenericElement::HandleDOMEvent() line 1961 + 47 bytes
PresShell::HandleEventInternal() line 6405 + 50 bytes
PresShell::HandleEvent() line 6288 + 25 bytes
nsViewManager::HandleEvent() line 2268

Comment 42

[Frank Tang]

leon: are you going to address sfraser's comments?

Comment 43

[leon.zhang]

I have discussed with simon about this patch.
we have agree with below:
1) cache is helpful to perf of mozilla in editor. 
2) if the perf of mozilla can not be improved, many hardware can not use mozilla
for perf issues( e.g. Network Computer).

IMHO, I think that this patch is not special-casing hack, it can make the cache
more robust. I still prefer this patch because it can resolve this bug and can
also keep perf editor improved when typing chars.

Comment 44

[Randell Jesup [:jesup] (needinfo me)]

If sfraser is ok with the patch now, get him to review+ it as soon as possible.
 Otherwise there's no way it's going to make it in for 1.4.

Comment 45

[kinmoz]

Comment on attachment 124066 [details] [diff] [review]
good format 

I really don't like this patch either.

Leon, I'm just curious, is this bug due to the fact that when you call
SetCanCacheFrameOffset(PR_FALSE), you aren't clearing out the cached frame and
pos ... which means that if it is ever turned back on again, there is a chance,
even after the reflow, that you might get a match and use a stale point?

Comment 46

[Frank Tang]

we need this bug fixed on both 1.4 branch and trunk.
For 1.4 branch, can we either
1. backout the origional change which cause this issue, or
2. produce a patch which turn off the cache like what sfraser suggest.  

and for trunk, we have more time to find the "right solution"

Comment 47

[bobj]

Yes, we need to get this resolved very quickly on the branch.
This bug is very bad.

Comment 48

[Katsuhiko Momoi]

Per Japanese Bugzilla (3174) info and discussion with sfraser, the two bug
fixes that have directly to do with this problem are in Bug 35296 comment #92
and Bug 199412. I'm asking sfraser to suggest a simple change to turn off
"offset cache".

Comment 49

[Simon Fraser [no longer active]]

The caret cache is enabled here:
http://lxr.mozilla.org/seamonkey/source/editor/libeditor/base/nsEditor.cpp#772

Removing the SetCanCacheFrameOffset(PR_TRUE); call should be enough to disable
the cache.

Comment 50

[Katsuhiko Momoi]

Attachment: a simple patch sugested by sfraser(just for 1.4)

Here's a simple patch suggested by sfraser.
I tried it against the 1.5 trunk build from early
morning of 2003-05-29. It seems to work well for Japanese
on Win XP.

I also tried QuanPin and ShuangPin methods for Chinese (PRC)
and it seems to work Ok though we need confirmation from someone
who uses Chinese IME regularly.

Comment 51

[leon.zhang]

Attachment: patch just for 1.4

Comment 52

[Katsuhiko Momoi]

Comment on attachment 124521 [details] [diff] [review]
patch just for 1.4

Requesting review & superreview for 1.4 branch checkin

Comment 53

[Katsuhiko Momoi]

I tried the patch in comment #51 against the latest 1.4 branch build.
It works as intended resolving all the known issues reported earlier
in this bug for Japanese and Chinese. For Chinese, I am not an everyday
IME user and so would be nice to have confirmation from someone who uses
QuanPin and ShuangPin methods regularly. 
Requested review & super-review for 1.4 branch only checkin.

Comment 54

[kinmoz]

Comment on attachment 124521 [details] [diff] [review]
patch just for 1.4

sr=[e-mail] if you are looking for the absolute minimal number of lines
to fix this bug, but personally I prefer to ifdef out all of the caching code
in that method, since that method is called *every* time you type or perform an
edit action.

As for risk assesment, it should be minimal, and will cause us to fallback to
calculating the caret position every time, as was done in all previous
releases.

Comment 55

[kinmoz]

Attachment: Patch just for 1.4 (ifdef version)

Here's an ifdef version of the patch to turn off caching in the editor, just in
case others feel the same way.

By the way, this type of bug was exactly what we were concerned about in bug
35296 comment #45.

Comment 56

[Simon Fraser [no longer active]]

Comment on attachment 124521 [details] [diff] [review]
patch just for 1.4

r=sfraser, but we might as well just #ifdef it out, as kin's patch does.

Comment 57

[Katsuhiko Momoi]

I tested kin's ifdef version on 1.4 branch build and it works as
intended resolving all the known issues in this bug. 
I'll obsolete the other patch and will request review for the
ifdef version next.

Comment 58

[Katsuhiko Momoi]

Comment on attachment 124521 [details] [diff] [review]
patch just for 1.4

Obsoleted in favor of the ifdef version.

Comment 59

[Katsuhiko Momoi]

Comment on attachment 124549 [details] [diff] [review]
Patch just for 1.4 (ifdef version)

Requesting a review and a superreview.
And a 1.4 branch checkin.

Comment 60

[Asa Dotzler [:asa]]

Comment on attachment 124549 [details] [diff] [review]
Patch just for 1.4 (ifdef version)

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 61

[Kathleen :Brade]

Comment on attachment 124549 [details] [diff] [review]
Patch just for 1.4 (ifdef version)

r=brade

Comment 62

[Samir Gehani]

a=adt to land on the 1.4 branch.

Comment 63

[Katsuhiko Momoi]

Is it then OK to check in also the other patch

http://bugzilla.mozilla.org/attachment.cgi?id=123950&action=view

for Chinese input? It has a review & a superreview aleady but not a specific
1.4 approval. How about a risk factor?

Someone with a check in privilege, please check these 2 in when the 
above question is resolved.

Comment 64

[leon.zhang]

Attachment: simple solution for trunk

we should clean up our cache, if we do not use it.

Comment 65

[Asa Dotzler [:asa]]

Comment on attachment 123950 [details] [diff] [review]
fix crash when type chinese chars into composer

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 66

[Katsuhiko Momoi]

Leon, your patch in comment #64 did not work for the trunk build. 
I saw no improvement in terms of Japanese IME.
Let me file a separate bug to manage further fix attempts on the 
trunk for this problem.

In the meantime,

http://bugzilla.mozilla.org/attachment.cgi?id=123950&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=124549&action=view

These 2 patches have been approved for a checkin into 1.4 branch.
Leon or someone with a check in privilege, please check these 2 in
as soon as possible.

I created Bug 207936 so that further improvement can be pursued on
the trunk. This bug is already long and it would be best to close
it after the verification for 1.4 branch.

Changed the summray to reflect the branch only status.

Comment 67

[leon.zhang]

checked  patches below  into branch1.4:
http://bugzilla.mozilla.org/attachment.cgi?id=123950&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=124549&action=view

further solution will be given in bug 207936

Comment 68

[leon.zhang]

http://bugzilla.mozilla.org/attachment.cgi?id=123950&action=view
has been checked into trunk and branch 1.4

http://bugzilla.mozilla.org/attachment.cgi?id=124549&action=view
has been checked into branch 1.4 

Comment 69

[leon.zhang]

fixed

Comment 70

[Yuying Long]

Verified fixed in 1.4 06-03linux, 06-02 Mac and Windows branch.