<Swing Dev> [10] RFR JDK-8176072: READING attributes are not available on TSF

Semyon Sadetsky semyon.sadetsky at oracle.com
Thu Nov 16 18:51:56 UTC 2017

Hi Sreeprakash,

Shouldn't the AwtInputTextInfor::GetAttributeInfor be readdressed to 
m_pResultTextInfor as well?


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20171116/76b11952/attachment.html>

More information about the swing-dev mailing list