Hi Alexander, thanks for review!
is there another volunteer?
Thanks!
Anton.
On 25.06.2014 18:23, Alexander Scherbatiy wrote:
The fix looks good to me.
Thanks,
Alexandr.
On 6/25/2014 5:36 PM, anton nashatyrev wrote:
Hi Alexander,
this works on the current testcase.
What makes me more confident is that before the fix JDK-4502121 a
negative dimension was also possible and the methods you mentioned
might be called with such values. It seems the class didn't changed
dramatically since that time.
Thanks!
Anton.
On 25.06.2014 17:12, Alexander Scherbatiy wrote:
Removing isEmpty variable checking logic leads that some methods
(adjustForVSB(...), viewport.toViewCoordinates(...)) could use a
rectangle with negative sizes.
Do these methods work properly in this case?
Thanks,
Alexandr.
On 6/24/2014 8:31 PM, anton nashatyrev wrote:
Hello,
could you please review the following fix:
fix: http://cr.openjdk.java.net/~anashaty/8044371/9/webrev.00/
<http://cr.openjdk.java.net/%7Eanashaty/8044371/9/webrev.00/>
bug: https://bugs.openjdk.java.net/browse/JDK-8044371
Problem:
After the ScrollPane which is scrolled to the bottom resized to
the width 0 and then back its vertical scroll position changes.
Evaluation:
this is the regression from the fix JDK-4502121
<https://bugs.openjdk.java.net/browse/JDK-4502121>.
When the viewport size is 0 the
ScrollPaneLayout.layoutContainer decides not to paint/layout the
scrollbars and the viewport height is calculated with no respect to
horizontal scrollbar height. The viewport height thus becomes
larger and its position shifts 25 pixels (the height of the
horisontal scrollbar) up. The expand action doesn't revert the
position which is a normal behavior.
Fix:
modify the fix for JDK-4502121
<https://bugs.openjdk.java.net/browse/JDK-4502121>, so it still
solves the original problem, but doesn't add the unwanted behavior:
the layout should take into account the scrollbars even if the size
of the scrollpane is 0.
Thanks!
Anton.
