<Swing Dev>  RFR JDK-8176072: READING attributes are not available on TSF
semyon.sadetsky at oracle.com
semyon.sadetsky at oracle.com
Fri Nov 17 16:10:04 UTC 2017
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 :
> Thanks And Regards,
> *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>  RFR JDK-8176072: READING attributes
> are not available on TSF
> 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 :
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swing-dev