<AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

Semyon Sadetsky semyon.sadetsky at oracle.com
Wed Feb 28 19:08:31 UTC 2018


Hi Sashi,

The parent with and height shouldn't be decreased by the size of the 
scrollbars in case of SCROLLBARS_NEVER.

--Semyon


On 2/27/2018 12:45 AM, Shashidhara Veerabhadraiah wrote:
>
> 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/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/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 <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *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
>         <semyon.sadetsky at oracle.com
>         <mailto:semyon.sadetsky at oracle.com>> 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<shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>             <mailto:awt-dev at openjdk.java.net>
>             *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<shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                 <mailto:awt-dev at openjdk.java.net>
>                 *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<shashidhara.veerabhadraiah at oracle.com>
>                     <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                     <mailto:awt-dev at openjdk.java.net>
>                     *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
>

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


More information about the awt-dev mailing list