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/ 

 

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 HYPERLINK 
"https://bugs.openjdk.java.net/browse/JDK-8176072?focusedCommentId=14131714&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14131714"JBS-Comment)

 

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

 

 

Reply via email to