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