Hi Shashi,
This test passes for me without any problems on my machine. I'm using Windows
10 build 1703 - i.e it is not Fall Creators build.
Also, the intent of the test is to check that, if a frame is drawn on top of
another frame, then the mouse move should be seen by the top frame and not the
bottom frame. Since we use Robot.mouseMove, I guess it should move to the exact
location that we specify.
Frame2 is created at position (120,120). The mouse is moved to (149, 149) first
and then to (150,150). So, effectively, mouse position should be (30,30) wrt
second frame. I don't see a reason for adding some sort of threshold here like
your fix suggests.
And also, since Frame2 is on top, frame2 should see the MouseMove, whereas
Frame1 shouldnot see it.
There was a test bug JDK- 8027154, where a fix was done.
Thanks,
Krishna
Message: 1
Date: Mon, 26 Feb 2018 20:45:31 -0800 (PST)
From: Shashidhara Veerabhadraiah
<[email protected]>
To: Philip Race <[email protected]>
Cc: [email protected]
Subject: Re: <AWT Dev> [11] JDK-8196017:
java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
fails
Message-ID: <1a170b63-391b-416d-9cc2-4e66e2a63a76@default>
Content-Type: text/plain; charset=us-ascii
Am using Windows 10 Pro Version: 1703!! Do you suspect this has those
specific mouse move issues?
Thanks and regards,
Shashi
-----Original Message-----
From: Philip Race
Sent: Tuesday, February 27, 2018 10:12 AM
To: Shashidhara Veerabhadraiah <[email protected]>
Cc: Sergey Bylokhov <[email protected]>; [email protected]
Subject: Re: <AWT Dev> [11] JDK-8196017:
java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
What Windows 10 version are you running ? As discussed a few times ...
probably off-list ..
there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse moves.
-phil.
On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Before I sent out this review I ran this test different platforms
> and saw that it was passing. But then after I sent it out for review I found
> that the test had not run on Windows 10!! That was strange and was not
> expecting it in the first place. I found that mouseMoved() event was never
> received for the frame 2!! And our test passes or fails within the frame 2's
> mouseMoved() event callback.
>
> We do receive this event on mac and win 7 and am not sure why are we missing
> it on win 10. So I think it is good to make this test specific to mac as the
> original fix was specific to mac only and log a new bug to debug on this
> problem. I do not see as an issue with test as it is a simple test and it
> falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154
> was a test only update.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, February 27, 2018 4:05 AM
> To: Shashidhara Veerabhadraiah<[email protected]>;
> [email protected]
> Subject: Re:<AWT Dev> [11] JDK-8196017:
> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
> fails
>
> Hi, Shashi.
> Why this test should be platform specific? It shows two common frames and use
> some generic api for mouse events.
> This test also was updated in JDK-8027154 and I assume it should works on
> macOS after that, maybe we have a new regression here?
>
> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a test fix for the below bug:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>
>> Summary: The original bug
>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only
>> for MacOS platform but the test is enabled to run on all platforms.
>> This is modified. Along with it exact positional comparison was done
>> in the test and now modified to allow for leniency of around 2 pixels.
>>
>> Thanks and regards,
>> Shashi
>>
>
> --
> Best regards, Sergey.
------------------------------
Message: 2
Date: Mon, 26 Feb 2018 21:20:49 -0800 (PST)
From: Prem Balakrishnan <[email protected]>
To: Sergey Bylokhov <[email protected]>,
[email protected]
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression
automated Test
'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
fails
Message-ID: <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>
Content-Type: text/plain; charset=us-ascii
Hi Sergey,
At times backFrame is rendered on top of frontFrame, due to which mouse
position on backFrame is not NULL and test fails, solved this by adding
waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to
backFrame, caused the cursor to change to resize cursor and test fails, solved
this by setting setResizable() to false.
Regards,
Prem
-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, February 27, 2018 3:59 AM
To: Prem Balakrishnan <[email protected]>; [email protected]
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
fails
Hi, Prem.
> Test fails due to synchronization issue.
Can you please clarify what synchronization issue was fixed? The code
before/after mostly identical except xxx.setResizable(false);
--
Best regards, Sergey.
------------------------------
Message: 3
Date: Mon, 26 Feb 2018 21:45:18 -0800
From: Phil Race <[email protected]>
To: Shashidhara Veerabhadraiah <[email protected]>
Cc: [email protected]
Subject: Re: <AWT Dev> [11] JDK-8196017:
java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
fails
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Could be that it acquired the same bug via a patch release.
-Phil.
> On Feb 26, 2018, at 8:45 PM, Shashidhara Veerabhadraiah
> <[email protected]> wrote:
>
> Am using Windows 10 Pro Version: 1703!! Do you suspect this has those
> specific mouse move issues?
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Philip Race
> Sent: Tuesday, February 27, 2018 10:12 AM
> To: Shashidhara Veerabhadraiah <[email protected]>
> Cc: Sergey Bylokhov <[email protected]>; [email protected]
> Subject: Re: <AWT Dev> [11] JDK-8196017:
> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
>
> What Windows 10 version are you running ? As discussed a few times ...
> probably off-list ..
> there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse
> moves.
>
> -phil.
>
>> On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
>> Hi Sergey, Before I sent out this review I ran this test different platforms
>> and saw that it was passing. But then after I sent it out for review I found
>> that the test had not run on Windows 10!! That was strange and was not
>> expecting it in the first place. I found that mouseMoved() event was never
>> received for the frame 2!! And our test passes or fails within the frame 2's
>> mouseMoved() event callback.
>>
>> We do receive this event on mac and win 7 and am not sure why are we missing
>> it on win 10. So I think it is good to make this test specific to mac as the
>> original fix was specific to mac only and log a new bug to debug on this
>> problem. I do not see as an issue with test as it is a simple test and it
>> falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154
>> was a test only update.
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, February 27, 2018 4:05 AM
>> To: Shashidhara Veerabhadraiah<[email protected]>;
>> [email protected]
>> Subject: Re:<AWT Dev> [11] JDK-8196017:
>> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
>> fails
>>
>> Hi, Shashi.
>> Why this test should be platform specific? It shows two common frames and
>> use some generic api for mouse events.
>> This test also was updated in JDK-8027154 and I assume it should works on
>> macOS after that, maybe we have a new regression here?
>>
>>> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please review a test fix for the below bug:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>>
>>> Summary: The original bug
>>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only
>>> for MacOS platform but the test is enabled to run on all platforms.
>>> This is modified. Along with it exact positional comparison was done
>>> in the test and now modified to allow for leniency of around 2 pixels.
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>
>> --
>> Best regards, Sergey.
------------------------------
Message: 4
Date: Tue, 27 Feb 2018 00:45:26 -0800 (PST)
From: Shashidhara Veerabhadraiah
<[email protected]>
To: Semyon Sadetsky <[email protected]>
Cc: [email protected]
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane
is reset after calling validate()
Message-ID: <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
Content-Type: text/plain; charset="utf-8"
Hi Semyon, Thanks for your help. I did some debugging from that perspective and
could find the problem and the solution. Here is the new webrev, please review
it:
?
http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/
?
The problem was that in the case of SCROLLBARS_NEVER, scroll bar info was set
using setScrollInfo() with SIF_RANGE with ranges being (0, 0). This forced the
windows to pick a default value and hence reset it to that value every time.
Now the logic is modified in a very similar fashion as the other scroll bar
display modes but without displaying it using the new win api ShowScrollBar().
The scroll bar info is supplied with a proper range per the corresponding base
component but without the scroll bar pane size(as we don?t display it). This
should suffice a good range for the scroll bars to operate and correct itself
if there is any out of range value is supplied.
?
Thanks and regards,
Shashi
?
From: Semyon Sadetsky
Sent: Tuesday, February 27, 2018 1:22 AM
To: shashidhara veerabhadraiah <[email protected]>
Cc: [email protected]
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset
after calling validate()
?
The bug was failed against Windows platform. So, I'd try to find the root cause
why when the scroll is notified with the scrolled component size the scroll
position is set to the wrong value.
--Semyon
?
On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
I think I agree Semyon. Thanks for your detailed explanation.
?
So how do we approach on this? I see a different behaviour on other platforms.
Shouldn?t we have a common behaviour across platforms? I agree with your
analysis and hence should we change the behaviour on other platforms so that
all of them will have the same behaviour?
?
Thanks and regards,
Shashi
?
On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky <HYPERLINK
"mailto:[email protected]"[email protected]> wrote:
?
On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
Hi Semyon, Thanks for your review and these questions help us to reach the
right requirements.?
?
Without this change, there is different behavior on windows compared to
Mac/Linux platforms. Hence this change is required to make the behavior same
across the platforms. Since the scroll pane control is not displayed for the
SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the
user can move to a different position? Since we used to update/recalculate the
scroll pane geometry caused changes to move to a different position other than
the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as the
user is unable to control the scrolling movement because neither he can set one
setScrollPosition() nor the control is displayed to explicitly set the
movement. Hope this answers your question.
You need to think once again about two facts I brought in my previous message.
1. User still may scroll using mouse wheel even when scrollbars are not visible.
2. Visibility of scrollbars doesn't affect the requirement to notify the scroll
about the scrolled component size changes. If the scrolled component was
500x500 in size and its position in the 200x200 viewport was (300,300) after
the size of the component is changed to 300x300 it may not be shown at the same
position because the previously visible component area doesn't exist anymore
and the scroll should be moved to (100,100). This should work in the same way
regardless the selected scrlollbar visibility policy.
--Semyon
?
Thanks and regards,
Shashi
?
From:?Semyon Sadetsky?
Sent:?Saturday, February 24, 2018 2:12 AM
To:?Shashidhara Veerabhadraiah?HYPERLINK
"mailto:[email protected]";<[email protected]>;?HYPERLINK
"mailto:[email protected]"[email protected]
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset
after calling validate()
?
On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
Hi Semyon, Whenever the container is resized we used to update the scroll pane
sizes/geometry regardless of the scroll bar display policies. This resizing
make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed
or needed an update. This additional update posed issues for the
SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per
the java doc, then why update?
?
Scroll pane geometry gets updated in 2 ways, one thro? setScrollPosition() and
childResized(). So I derived the conclusion based on the javadoc information
that since we don?t display the scroll pane there is no need to update the
scroll pane geometry based on the childResized() as it was altering the
position already set by the setScrollPosition(). This behavior is same as the
other non SCROLLBARS_NEVER mode and setting the scroll bar display to
SCROLLBARS_NEVER didn?t made any difference.
The only difference of SCROLLBARS_NEVER from others I got from javadoc is that
the scroll bar controls are hidden. So the scrolling itself happens in the same
way as in the case of visible scroll bars but it can be only controlled by
mouse wheel or programmatically. In my understanding this means that the
notification about the scrolled component size changes should happen in the
same way as for all other cases. I see no reason for the differentiation that
your fix introduces. What will happen if to remove this notification for
visible scroll bars modes?
--Semyon
?
Thanks and regards,
Shashi
?
From:?Semyon Sadetsky?
Sent:?Friday, February 23, 2018 10:17 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK
"mailto:[email protected]";<[email protected]>;?HYPERLINK
"mailto:[email protected]"[email protected]
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset
after calling validate()
?
On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
Hi Semyon, Thanks for your review comments.
?
Here are those different scroll bar pane modes and their description:
Modifier and Type
Field
Description
static int
HYPERLINK
"https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS
Specifies that horizontal/vertical scrollbars should always be shown regardless
of the respective sizes of the scrollpane and child.
static int
HYPERLINK
"https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED
Specifies that horizontal/vertical scrollbar should be shown only when the size
of the child exceeds the size of the scrollpane in the horizontal/vertical
dimension.
static int
HYPERLINK
"https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER
Specifies that horizontal/vertical scrollbars should never be shown regardless
of the respective sizes of the scrollpane and child.
?
This javadoc, you've copy-pasted here, doesn't explain why in your fix the
notification about changed child size is disabled for SCROLLBARS_NEVER case.
Thanks and regards,
Shashi
?
From:?Semyon Sadetsky?
Sent:?Thursday, February 22, 2018 11:58 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK
"mailto:[email protected]";<[email protected]>;?HYPERLINK
"mailto:[email protected]"[email protected]
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset
after calling validate()
?
Hi Shashi,
Can you clarify what is the principal difference between SCROLLBARS_NEVER and
other scroll policies that requires to avoid updating the scroll geometry
according to the inner component size?
--Semyon
On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:
Hi All, Please review a code fix for the below bug.
?
Bug:?https://bugs.openjdk.java.net/browse/JDK-8195738
?
Webrev:?HYPERLINK
"http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
?
Problematic platform: Windows only.
?
Summary: This bug occurs only on windows platform and whereas the behavior is
different on Mac/Linux platforms. Now after this fix there is common behavior
across the platforms.
The main problem was with resetting the state of the scroll bars even though
the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar
display policy. This resetting should not occur as the scroll bar display
policy makes the?
scroll bar panes invisible. Hence except the setScrollPosition() calls, we
don?t need to resize/update the scroll bars state upon calling the scroll bars
validation if SCROLLBARS_NEVER policy is used as the scroll bars are not
displayed.
?
Thanks and regards,
Shashi
?
?
?
?
?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180227/6d746987/attachment.html>
End of awt-dev Digest, Vol 130, Issue 41
****************************************
