Hi Sreeprakash,
Shouldn't the AwtInputTextInfor::GetAttributeInfor be readdressed to
m_pResultTextInfor as well?
--Semyon
On 11/16/2017 08:36 AM, Sreeprakash Sreedharan wrote:
Hello All,
Please review the following fix in JDK10.
Bug : https://bugs.openjdk.java.net/browse/JDK-8176072
Webrev :
http://cr.openjdk.java.net/~ssreedharan/8176072/jdk10/webrev.00/
<http://cr.openjdk.java.net/%7Essreedharan/8176072/jdk10/webrev.00/>
The bug describes a scenario wherein reading
(AttributedCharacterIterator.Attribute.READING) attributes are not
obtained from the InputMethodEvent text. (Japanese IME)
(Detailed summary is provided in the JBS-Comment
<https://bugs.openjdk.java.net/browse/JDK-8176072?focusedCommentId=14131714&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14131714>)
Issue:
This issue is seen when IMM sends WM_IME_COMPOSITION with both
GCS_COMPSTR and GCS_RESULTSTR. The scenario is handled in
AwtInputTextInfor::GetContextData, where we extract the result string
using the GCS_RESULTSTR data and store it in m_pResultTextInfor,
member variable inside the main AwtInputTextInfor. Along with the
result string the READING attributes of the first portion of the
string is also stored in m_pResultTextInfor. The main
AwtInputTextInfor stores the data represented by GCS_COMPSTR. When
GetClauseInfor is called on the main AwtInputTextInfor, it just checks
whether the read clause is present within it. If it’s not present, it
just returns NULL even though the GCS_RESULTSTR data present within
m_pResultTextInfor has READING attributes present.
Solution :
In GetClauseInfor, made sure that even if the main AwtInputTextInfor
doesn't have any clause and Reading information it still checks for
the GCS_RESULTSTR data held in m_pResultTextInfor.
Also in WInputMethod.java, there was a condition which checks whether
the last element in clauseBoundary is equal to length of the text
entered. This is an incorrect assumption, as proven in the test case.
Here, the last element of clauseBoundary comes as 2 (length of the
Japanese String formed after typing 'a','b','e','space','space'), but
the final text now has the new character 's' added and the total
length will be 3.
The test case added requires the user to change to Japanese IME and
hence its manual.
I have run all relevant JTREG test cases and Mach5 jobs and didn't see
any failures.
Regards,
Sreeprakash
