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

[semyon.sadetsky at oracle.com]

+1

--Semyon


On 11/17/17 4:35 AM, Sreeprakash Sreedharan wrote:
>
> Hi Semyon,
>
> Thanks for your inputs. You are right about the need for redirecting 
> AwtInputTextInfor::GetAttributeInfor also to m_pResultTextInfor.
>
> 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.
>
> 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.
>
> This could probably explain why GetAttributeInfor was never redirected 
> to m_pResultTextInfor and the results were only merged.
>
> But there is still a theoretical possibility of this happening.
>
> I have updated the webrev with this change.
>
> Updated Webrev : 
> http://cr.openjdk.java.net/~ssreedharan/8176072/jdk10/webrev.01/ 
> <http://cr.openjdk.java.net/%7Essreedharan/8176072/jdk10/webrev.01/>
>
> Thanks And Regards,
>
> Sreeprakash
>
> *From:*Semyon Sadetsky
> *Sent:* Friday, November 17, 2017 12:22 AM
> *To:* Sreeprakash Sreedharan <sreeprakash.s at oracle.com>; 
> awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
> *Subject:* Re: <Swing Dev> [10] RFR JDK-8176072: READING attributes 
> are not available on TSF
>
> 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
>

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