976466 - [android] Scroll position isn't always maintained when hitting back.

Status: VERIFIED FIXED

(Marketplace Graveyard :: Consumer Pages, defect, P2)

Description

[Stuart Colville [:muffinresearch]]

STR: 


 * Using FF Android  
 * Navigation to http://marketplace-dev.allizom.org.
 * Scroll down the homepage and notice what app is at the top of the screen.
 * Click on that app
 * See the position that that page is loaded in.
 * Click the back arrow
 * See if the scroll position is retained.

What should happen:

 * App should be loaded and be at the top of the app page.
 * When pressing back the original scroll position should be restored.

What happens.

 * The attempt to scroll happens too fast and results in an incorrect scroll position.
 

Potential solution. Add a small delay before calling scrollTo to ensure page is ready to scroll.

Comment 1

[Stuart Colville [:muffinresearch]]

https://github.com/mozilla/fireplace/commit/151107b4138fd5eae0b842b77f97aef2c1b63690

Comment 2

[Stuart Colville [:muffinresearch]]

Linking PR for additional details re: why this isn't using an event:  https://github.com/mozilla/fireplace/pull/378

Comment 3

[Victor Carciu]

Verified as fixed. 
I opened apps from different scroll positions and after pressing back,  the original scroll position was restored.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

1. Load https://marketplace-dev.allizom.org
2. Scroll down to the bottom of the Popular section.
3. Click the YouTube icon.
4. Even after the detail page is loaded, we wait for a significant amount of time at the previous scroll position before jumping up to the top of the page.

This looks really awkward and I keep thinking things are broken when I see this.

Comment 5

[Stuart Colville [:muffinresearch]]

(In reply to Christopher Van Wiemeersch [:cvan] from comment #4)
> 1. Load https://marketplace-dev.allizom.org
> 2. Scroll down to the bottom of the Popular section.
> 3. Click the YouTube icon.
> 4. Even after the detail page is loaded, we wait for a significant amount of
> time at the previous scroll position before jumping up to the top of the
> page.
> 
> This looks really awkward and I keep thinking things are broken when I see
> this.

I've filed a new bug for this with your str (bug 986625). Unfortunately thus far it's the case that whilst one would expect scrolling to the top of a page to always work it doesn't if it's called too soon and the result of being left halfway down the newly loaded content is worse than the delay. 

The new bug will give us place to track experimenting further to see if there's a better workaround or a new approach that would make it much faster. Or alternatively we could consider a completely different tack e.g. some kind of page transition to prevent this from being visible.