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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
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/

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
Reply | Threaded
Open this post in threaded view
|

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

Semyon Sadetsky
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

Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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

Semyon Sadetsky
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
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 <[hidden email]> 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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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

Semyon Sadetsky
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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
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.

Thanks and regards,
Shashi

-----Original Message-----
From: Semyon Sadetsky
Sent: Wednesday, January 17, 2018 10:58 PM
To: shashidhara veerabhadraiah <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Semyon Sadetsky
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 <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
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.


Thanks and regards,
Shashi

On 18-Jan-2018, at 9:55 PM, Semyon Sadetsky <[hidden email]> 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 <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: <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.

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 <[hidden email]> 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 <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
Hi Semyon, Please find the new web rev containing those changes:


With this the HidiingSelectionTest passes as well as the original JCK test that got failed against this bug passes.

Thanks and regards,
Shashi

On 19-Jan-2018, at 9:47 PM, Semyon Sadetsky <[hidden email]> wrote:

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.

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 <[hidden email]> 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 <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

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

Semyon Sadetsky

+1

Fill free to file a new bug if you think that other tests or the current selection behavior need to amended.

--Semyon


On 1/19/18 10:14 AM, shashidhara veerabhadraiah wrote:
Hi Semyon, Please find the new web rev containing those changes:


With this the HidiingSelectionTest passes as well as the original JCK test that got failed against this bug passes.

Thanks and regards,
Shashi

On 19-Jan-2018, at 9:47 PM, Semyon Sadetsky <[hidden email]> wrote:

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.

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 <[hidden email]> 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 <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

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

Shashidhara H V
Thanks and sure Semyon. Will file if required.

On 19-Jan-2018, at 11:42 PM, [hidden email] wrote:

+1

Fill free to file a new bug if you think that other tests or the current selection behavior need to amended.

--Semyon


On 1/19/18 10:14 AM, shashidhara veerabhadraiah wrote:
Hi Semyon, Please find the new web rev containing those changes:


With this the HidiingSelectionTest passes as well as the original JCK test that got failed against this bug passes.

Thanks and regards,
Shashi

On 19-Jan-2018, at 9:47 PM, Semyon Sadetsky <[hidden email]> wrote:

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.

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 <[hidden email]> 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 <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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






Reply | Threaded
Open this post in threaded view
|

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

Sergey Bylokhov
+1

On 19/01/2018 10:23, shashidhara veerabhadraiah wrote:

> Thanks and sure Semyon. Will file if required.
>
>> On 19-Jan-2018, at 11:42 PM, [hidden email]
>> <mailto:[hidden email]> wrote:
>>
>> +1
>>
>> Fill free to file a new bug if you think that other tests or the
>> current selection behavior need to amended.
>>
>> --Semyon
>>
>>
>> On 1/19/18 10:14 AM, shashidhara veerabhadraiah wrote:
>>> Hi Semyon, Please find the new web rev containing those changes:
>>>
>>> http://cr.openjdk.java.net/~sveerabhadra/8194135/webrev.03/ 
>>> <http://cr.openjdk.java.net/%7Esveerabhadra/8194135/webrev.03/>
>>>
>>> With this the HidiingSelectionTest passes as well as the original JCK
>>> test that got failed against this bug passes.
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>>> On 19-Jan-2018, at 9:47 PM, Semyon Sadetsky
>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> 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
>>>>>> <[hidden email] <mailto:[hidden email]>>
>>>>>> 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
>>>>>>> <[hidden email]
>>>>>>> <mailto:[hidden email]>>
>>>>>>> Cc: [hidden email] <mailto:[hidden email]>
>>>>>>> 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
>>>>>>>>> <[hidden email]
>>>>>>>>> <mailto:[hidden email]>> 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
>>>>>>>>>>> <[hidden email]
>>>>>>>>>>> <mailto:[hidden email]>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>


--
Best regards, Sergey.