This bug is very similar to bug #39284.
I can reproduce this issue in Chrome 15.0.874.121 m on Windows 7 64-bit. Also confirmed in Safari 5.1.1 on Mac OS X 10.7.2. So far I it does not seem platform-specific. This issue does not occur in any recent version of Firefox. Also can reproduce in Internet Explorer 9, so this may be a result of a similar implementation method.
I can post a simplified testcase later this week, but have a live site where the issue can be reproduced.
Steps to reproduce:
1. Load http://www.grovo.com/twitter-ipad-app/twitter-ipad-app-introduction
2. Pause the video once it starts playing (to prevent automatic scrolling behavior which may confuse you while trying to reproduce).
3. Click on the Engage tab (to the right of the video player).
3. Scroll to another position within the now-shown #engagebox-container element.
4. Switch to either the Lessons or Transcript tab (which will hide #engagebox, #engagebox-container's parent).
5. Switch back to the Engage tab (which will set display: block on #engagebox).
The scrollbar's position should be the same as before the element was hidden and shown again. #engagebox-container element's scrollTop value should not be set to 0 every time the parent element is hidden.
The scrollbar's position has been set to the top, as a result of the scrollTop property for #engagebox-container being set to 0.
Nickolay: This does not seem to be caused by the same issue as #39284. I attempted to set the CSS overflow property to hidden and other values on the #engagebox element, and the scrollTop value did not change.