227721 - Type-ahead find should work with a syllable in IME composition (if possible)

Status: RESOLVED INVALID

(SeaMonkey :: Find In Page, defect)

Description

[Isaac Hwak Han]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031207
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031207

Current mozilla type-ahead find behavior is annoying for Korean users because it
doesn't count a character in IME composition as part of valid query.


Reproducible: Always

Steps to Reproduce:
1. Open the testcase
2. Type '/' (invoking type-ahead find feature)
3. Switch to IME mode

Type in following sequences.

A) ㅎ (ㅎ)
B) ㅏ (하)
C) ㄴ (한)
D) ㄱ (한ㄱ)
E) ㅜ (한구)
F) backspace (한ㄱ)
G) ㅡ (한그)
H) ㄹ (한글)
I) F3 or arrow key (force to end TPA)
Actual Results:  
In each composition state A)-I), the type-ahead find highlight and the status
bar feed back show up as:

     Actual query    Highlight      Status bar
------------------------------------------------
A)        ㅎ            none            ㅎ 
B)        하            none            하
C)        한            none            한
D)        한ㄱ          3. 한           ㄱ
E)        한구          3. 한           구
F)        한ㄱ          3. 한           ㄱ
G)        한그          3. 한           그
H)        한글          3. 한           글
I)        한글          5. 한글     Text found: "한글"

Expected Results:  
     Actual query    Highlight      Status bar
------------------------------------------------
A)        ㅎ            1. ㅎ       Text found: "ㅎ"
B)        하            2. 하       Text found: "하"
C)        한            3. 한       Text found: "한"
D)        한ㄱ          4. 한국     Text found: "한ㄱ"
E)        한구          4. 한국     Text found: "한구"
F)        한ㄱ          4. 한국     Text found: "한ㄱ"
G)        한그          5. 한글     Text found: "한그"
H)        한글          5. 한글     Text found: "한글"
I)        한글          5. 한글     Text found: "한글"

During each phase, C) and H) is especially annoying, because the user think she
have just entered a valid syllable. She can press F3 or any arrow key to
manually end the search, but it's cumbersome enough to make the feature useless.
Other enhancements may be optional to implement, but mozilla uses UTF-8 as
character set of the internal buffer, so I think it is possible to decompose a
syllable into 2 or 3 character combination.

It may be Korean-specific, but other Asian users could benefit from it.

Comment 1

[Isaac Hwak Han]

Attachment: testcase

testcase

Comment 2

[Isaac Hwak Han]

Attachment: testcase with bug report

Attaching new testcase, because bugzilla broke Korean glyphs in the report.

Comment 3

[Jungshik Shin]

Please, set the character encoding to UTF-8 before typing any non-ASCII
characters. Because the character encoding was neither Korean nor UTF-8 when you
entered comment #0 (with a lot of Korean characters), all Korean characters got
turned to NCRs making it  all but impossible to read your comment #0. Here's
recap in a 'human readable format':

3. Switch to IME mode

Type in following sequences.

A) ㅎ (ㅎ)
B) ㅏ (하)
C) ㄴ (한)
D) ㄱ (한ㄱ)
E) ㅜ (한구)
F) backspace (한ㄱ)
G) ㅡ (한그)
H) ㄹ (한글)
I) F3 or arrow key (force to end TPA)
  Actual Results:  
  In each composition state A)-I), the type-ahead find highlight and the status
  bar feed back show up as:

       Actual query    Highlight      Status bar
       ------------------------------------------------
       A)        ㅎ            none            ㅎ 
       B)        하            none            하
       C)        한            none            한
       D)        한ㄱ          3. 한           ㄱ
       E)        한구          3. 한           구
       F)        한ㄱ          3. 한           ㄱ
       G)        한그          3. 한           그
       H)        한글          3. 한           글
       I)        한글          5. 한글     Text found: "한글"

       Expected Results:  
            Actual query    Highlight      Status bar
            ------------------------------------------------
            A)        ㅎ            1. ㅎ       Text found: "ㅎ"
            B)        하            2. 하       Text found: "하"
            C)        한            3. 한       Text found: "한"
            D)        한ㄱ          4. 한국     Text found: "한ㄱ"
            E)        한구          4. 한국     Text found: "한구"
            F)        한ㄱ          4. 한국     Text found: "한ㄱ"
            G)        한그          5. 한글     Text found: "한그"
            H)        한글          5. 한글     Text found: "한글"
            I)        한글          5. 한글     Text found: "한글"

I guess this is not trivial to fix. I'm not familiar with Win32 IME-related APIs
to know if there's a way to get the content of the 'composition buffer' before
it's committed. 
On Linux, it's even worse...


As for the incremental search with 'Korean letter/Jamo' (instead of 'Korean
syllable') as a unit, I mentioned it on the Unicode mailing list recently.
That's certainly necessary for Korean, but so far the only problem that
implements the feature was Korean Emacs (HanEmacs by KIM Kanghee). Does MS Word
on Windows support that? 

Comment 4

[timeless]

i'm pretty sure we can get the buffers on windows if we want to...
i doubt this is a priority for anyone, and my priorities will soon shift such
that this will definitely not be anywhere near my radar :(.

I don't think word for windows has incremental search, i've never seen it there.
MSDev for windows has it ... but I've never tried typing foreign chars in it.

Comment 5

[Aaron Leventhal]

Jshin, will you take this?

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

[[e-mail]]

IME is no longer supported by FAYT.