<AWT Dev> [10] JDK-8194135: The content in textArea can not be pasted after clicking "Copy" button.

[Semyon Sadetsky]

On 01/18/2018 09:41 PM, shashidhara veerabhadraiah wrote:

> Hi Semyon, Here are the changes that you think unnecessary have been 
> reverted back. Other changes I have retained as is unless any user has 
> any comments on the behaviour. So as of now I have retained the same 
> behaviour as the native one.
>
> New web rev: 
> http://cr.openjdk.java.net/~sveerabhadra/8194135/webrev.02/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8194135/webrev.02/>
This change still contains 2 tests modifications which are unrelated to 
the TCK issue. If modifing XTextAreaPeer.java fixes the TCK test failure 
that is the only change should be left. Other changes require separate a 
bug.
>
> Thanks and regards,
> Shashi
>
>> On 18-Jan-2018, at 9:55 PM, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> On 01/18/2018 12:31 AM, Shashidhara Veerabhadraiah wrote:
>>> Hi Semyon, The test cases which were under the HidingSelectionTest 
>>> are copied to MultiSelectionTest along with other the multiple 
>>> selection test cases. On Linux platforms, a text selection is always 
>>> visible and vanishes the moment a second selection is made. Since 
>>> the Linux specific behavior can't be added to the generic 
>>> HidingSelectionTest, those test cases are added along with the 
>>> original test cases from HidingSelectionTest to the new 
>>> MultiSelectionTest class.
>> What is the reason to copy HidingSelectionTest to MultiSelectionTest 
>> to run it only on Linux? I don't see this as part requested in the 
>> TCK red issue.
>>
>> As for selection vanishing only when another text is selected in the 
>> same window. I'm not sure that this should be the rule. At first not 
>> all native apps follow that on Linux. And the second, we need to keep 
>> balance between native behavior and being cross-platform. When the 
>> behavior is ambiguous for the user we have to follow the native way 
>> but when there no such issues the behavior should be cross-platform. 
>> Anyway, in my understanding this topic is out of the scope of the 
>> issue you need to fix in this bug.
>>
>> --Semyon
>>
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>> -----Original Message-----
>>> From: Semyon Sadetsky
>>> Sent: Wednesday, January 17, 2018 10:58 PM
>>> To: shashidhara veerabhadraiah 
>>> <shashidhara.veerabhadraiah at oracle.com 
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>>
>>> Cc: awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>>> Subject: Re: [10] JDK-8194135: The content in textArea can not be 
>>> pasted after clicking "Copy" button.
>>>
>>> Hi Shashi,
>>>
>>>   Why you disabled  HidingSelectionTest.java for Linux platform? How 
>>> is it related to the TCK test failure?
>>>
>>> --Semyon
>>>
>>>
>>> On 01/16/2018 10:27 AM, shashidhara veerabhadraiah wrote:
>>>> Hi Semyon, I ran those tests and found to be passed on the selected 
>>>> platforms. Since in linux platforms, we can’t have multiple 
>>>> selections visible at the same time, I have made a different test 
>>>> MultiSelectionTest along with other test cases as is in the 
>>>> HidingSelectionTest. This test passes on the linux platform and 
>>>> fails on other platforms because of the behaviour change on the 
>>>> linux platform.
>>>>
>>>> Thanks and regards,
>>>> Shashi
>>>>
>>>>> On 16-Jan-2018, at 10:02 PM, Semyon Sadetsky 
>>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>> Hi Shashi,
>>>>>
>>>>> HidingSelectionTest may not pass after your change because the 
>>>>> component selection is not cleared after the input focus transfer 
>>>>> within the containing window.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 01/13/2018 03:32 AM, shashidhara veerabhadraiah wrote:
>>>>>> Hi Semyon, I think that the ownsSelection flag handles the cases 
>>>>>> well and no need for any other conditions I felt. I confirmed 
>>>>>> this by running the older test(HidingSelectionTest) on all the 
>>>>>> platforms and the tests passed. Please let me know any particular 
>>>>>> reasons for adding those conditions.
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Shashi
>>>>>>
>>>>>>> On 12-Jan-2018, at 10:08 PM, Semyon Sadetsky 
>>>>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Shashi,
>>>>>>>
>>>>>>> Why did change generic DefaultCaret class while only platform 
>>>>>>> specific behavior should be fixed?
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>>
>>>>>>> On 01/12/2018 02:22 AM, shashidhara veerabhadraiah wrote:
>>>>>>>> Hi All, Please review a fix for the bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8194135
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~sveerabhadra/8194135/webrev.00/
>>>>>>>> <http://cr.openjdk.java.net/%7Esveerabhadra/8194135/webrev.00/>
>>>>>>>>
>>>>>>>> Summary: The text selection visibility behaves differently on 
>>>>>>>> linux/solaris platforms compared to windows or Mac platforms. 
>>>>>>>> There were 2 related fixes that went in this area. There are: 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-5100950 and 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8188081. While fixing 
>>>>>>>> the bug 5100950, a mistake was made to clear out the selection 
>>>>>>>> data. This behaviour is NOT the native behaviour as found in 
>>>>>>>> other native applications. The behaviour always is to retain 
>>>>>>>> the selection data and control the visibility of it depending 
>>>>>>>> on the conditions. On linux flavours we display only one 
>>>>>>>> selection data and upon toggling active application we get to 
>>>>>>>> see the selection data of that particular application hence we 
>>>>>>>> never loose the data. These behaviour differences are tested 
>>>>>>>> via the test components attached with this fix.
>>>>>>>> Considering the time, this fix addresses only the awt text 
>>>>>>>> components like textarea and textfield. Both these classes uses 
>>>>>>>> the same caret implementation, hence a change to the XAWTCaret 
>>>>>>>> is sufficient to reflect to both the text components. Swing 
>>>>>>>> based text components will be addressed later if there are any 
>>>>>>>> issues found.
>>>>>>>>
>>>>>>>> Thanks and regards,
>>>>>>>> Shashi
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180119/e7ec0186/attachment.html>