<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:PMingLiU;
        panose-1:2 1 6 1 0 1 1 1 1 1;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Kartika;
        panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"\@PMingLiU";
        panose-1:2 1 6 1 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:windowtext'>Hi Semyon,<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Thanks for your inputs. You are right about the need for redirecting AwtInputTextInfor::GetAttributeInfor also to m_pResultTextInfor.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>This scenario can happen when for the main AwtInputTextInfor (having the composition string in this case), the size of the current composition string is zero or if there is a mismatch in the size of the composition attribute and the composition string. <o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>However, I have not yet been able to regenerate this scenario at all, as composition string being zero indirectly implies that WM_IME_COMPOSITION will not be send with GCS_COMPSTR.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>This could probably explain why GetAttributeInfor was never redirected to m_pResultTextInfor and the results were only merged.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>But there is still a theoretical possibility of this happening.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>I have updated the webrev with this change.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Updated Webrev : <a href="http://cr.openjdk.java.net/~ssreedharan/8176072/jdk10/webrev.01/">http://cr.openjdk.java.net/~ssreedharan/8176072/jdk10/webrev.01/</a> <o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Thanks And Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Sreeprakash<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='color:windowtext'><o:p> </o:p></span></a></p><span style='mso-bookmark:_MailEndCompose'></span><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='color:windowtext'>From:</span></b><span style='color:windowtext'> Semyon Sadetsky <br><b>Sent:</b> Friday, November 17, 2017 12:22 AM<br><b>To:</b> Sreeprakash Sreedharan <sreeprakash.s@oracle.com>; awt-dev@openjdk.java.net; swing-dev@openjdk.java.net<br><b>Subject:</b> Re: <Swing Dev> [10] RFR JDK-8176072: READING attributes are not available on TSF<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p>Hi Sreeprakash,<o:p></o:p></p><p>Shouldn't the AwtInputTextInfor::GetAttributeInfor be readdressed to m_pResultTextInfor as well?<o:p></o:p></p><p>--Semyon<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On 11/16/2017 08:36 AM, Sreeprakash Sreedharan wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Hello All,<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Please review the following fix in JDK10.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Bug : <a href="https://bugs.openjdk.java.net/browse/JDK-8176072">https://bugs.openjdk.java.net/browse/JDK-8176072</a> <o:p></o:p></p><p class=MsoNormal>Webrev : <a href="http://cr.openjdk.java.net/%7Essreedharan/8176072/jdk10/webrev.00/">http://cr.openjdk.java.net/~ssreedharan/8176072/jdk10/webrev.00/</a> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>The bug describes a scenario wherein reading (AttributedCharacterIterator.Attribute.READING) attributes are not obtained from the InputMethodEvent text. (Japanese IME)<o:p></o:p></p><p class=MsoNormal>(Detailed summary is provided in the <a href="https://bugs.openjdk.java.net/browse/JDK-8176072?focusedCommentId=14131714&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14131714">JBS-Comment</a>)<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Issue:<o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Solution :<o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal>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. <o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>The test case added requires the user to change to Japanese IME and hence its manual.<o:p></o:p></p><p class=MsoNormal>I have run all relevant JTREG test cases and Mach5 jobs and didn't see any failures.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Regards,<o:p></o:p></p><p class=MsoNormal>Sreeprakash<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p></blockquote><p class=MsoNormal><o:p> </o:p></p></div></body></html>