Closed Bug 1057103 Opened 10 years ago Closed 9 years ago

Scroll is not maintained on homepage from app detail pages

Categories

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

Product:
Marketplace Graveyard
Component:
Consumer Pages
Platform:
x86
Gonk (Firefox OS)
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
2015-03-03

People

(Reporter: krupa.mozbugs, Assigned: kngo)

References

Details

(Whiteboard: [cvanwillbuyyouadrink] [userman]) 

Connectivity: wifi
SIM used: --
Gaia/device: 1.4/hamachi


steps to reproduce:
1. Launch feeddev packaged app
2. Scroll to the bottom of feed and click More
3. Scroll some more and Click on one of the apps listed to load its details page
4. Hit back button to return to the Feed

expected behavior:
Scroll position is maintained


actual behavior:
user is back at the first "More" button
Is this something we typically do when we implement infinite scrolls? If so, this is probably P2/3. Otherwise, P4.
Assignee: nobody → kngo
Gonna do this later since it's not a blocker, it involves some rework with builder.js to work with injecting paginated data into Isotope.
(In reply to Chuck Harmston [:chuck] from comment #1)
> Is this something we typically do when we implement infinite scrolls? If so,
> this is probably P2/3. Otherwise, P4.

we retain scroll position in fireplace.
We currently do this for search results (for pre-feed and feed both), but it doesn't apply to the current (pre-feed) homepage design -- so in that way, it's new.

Splitting the difference between "we do it now" and "it's new", especially since the infinite scroll becomes finite with these small feed sizes.
Priority: -- → P3
Whiteboard: [comms-needed]
Can product set priority here please?
Keywords: productwanted
Whiteboard: [comms-needed] → [cvanwilltreat]
Flags: needinfo?(dbialer)
Whiteboard: [cvanwilltreat] → [cvanwillbuyyouadrink]
Can we please reassess the priority here? Seems like higher than a P3 to me. 

Even though Krupa already gave sufficient STR, I'm going to include my own STR because I already wrote this and I forgot this bug existed:

1. Load the Marketplace on mobile (I'm using prod in this example).
2. Scroll down to the third island ("Get Creative").
3. Click any app (I clicked "PhotoFunia").
4. Press the back button.
5. Notice your scroll position was not preserved and you start back at the top of the page!
Summary: Scroll is not maintained when user gets back to Feed from the apps details page → Scroll is not maintained on homepage from app detail pages
I reaccessed per your recommendation.  I moved up to a P2.  It seems this bug particularly bugs you.  I will put this project into the daily tracker so that it is on the radar and can be picked up.
Flags: needinfo?(dbialer)
Priority: P3 → P2
Keywords: productwanted
Whiteboard: [cvanwillbuyyouadrink] → [cvanwillbuyyouadrink] [userman]
(In reply to David Bialer [:dbialer] from comment #7)
> I reaccessed per your recommendation.  I moved up to a P2.  It seems this
> bug particularly bugs you.  I will put this project into the daily tracker
> so that it is on the radar and can be picked up.

Only this one heh. It used to work and now it doesn't. It's very sad times whenever you're using a site and go back to another page and you have to scroll all the way down and remember where you left off.
Blocks: Feed_OnDeck
No longer blocks: 1033040
Well, that was easier than expected.

https://github.com/mozilla/fireplace/pull/1047

I'm counting the drinks btw
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2015-03-03
Also adds pagination cache rewrite for app reviews listing page.
In app "Reviews" page the scroll down is not maintained, from app details page. Is this intended?
Please see the screencast: http://screencast.com/t/fpmC700n75P7
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It's expected. We currently only keep track of scroll when going back in the browser navigation stack. There is a bug to keep track of scroll in cases other than going "Back", but it is not implemented.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
For Reviews page, it is expected though, that you don't have to click Load More again to see that review you flagged.
(In reply to Kevin Ngo [:ngoke] from comment #13)
> It's expected. We currently only keep track of scroll when going back in the
> browser navigation stack. There is a bug to keep track of scroll in cases
> other than going "Back", but it is not implemented.

Verified as fixed on MP-dev FF39(Win 7) and FFOS 1.4 (Inari)
Postfix screencast: http://screencast.com/t/Ddd7HaQLPP2
Closing bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.