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
<[email protected] <mailto:[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<[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<[email protected]>
<mailto:[email protected]>;[email protected]
<mailto:[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|
*SCROLLBARS_ALWAYS
<https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
Specifies that horizontal/vertical scrollbars should always
be shown regardless of the respective sizes of the
scrollpane and child.
|static int|
*SCROLLBARS_AS_NEEDED
<https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#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|
*SCROLLBARS_NEVER
<https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#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<[email protected]>
<mailto:[email protected]>;[email protected]
<mailto:[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:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
<http://cr.openjdk.java.net/%7Esveerabhadra/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
