This occurs in HotJava with Frameset pages that contain Frames with scrollbars. In such case, A ScrollPane (DocumentPanel) has child ScrollPanes. Adjusting the scrollbar of a child and then leaving and returning to the page causes the scrollbars to reposition to (0,0) instead of remaining in their old positions, despite attempts by HotJava to reset the scrollbars to the correct positions.

Setting the scroll position calls setValue on the adjustables. setValue does nothing when the new value and the old value are the same. That's cool, except that the manual positioning sets the value to the one we one and an attempt to set it later to the same in order to get the visual display to be correct becomes a noop. The real problem is that the Java side thinks we are in the right state and the peer has unilaterally reset to the origin without telling the Java code.

The workaround I have found is to set the scroll position to the origin after caching the correct old value. Then when restoring the old value, the scroller will see that the restore value is different than what it has a really reset the value and notify the peer.