Back button from detail screen does not return to previous row position in inline list

[Stryker]

Hello, everyone. New user here experiencing a problem that appears to have occurred for some others in the past.

From an inline list (say row 50) I click an item to view the detail screen. When I click the Back button from the detail screen, I am returned to the inline list at the row 1 position.

Interestingly, when I click the Edit link from the inline list (say row 50), after clicking the Cancel or Submit buttons on that Edit screen I am returned to the row 50 position.

The following links appear to describe the same problem occurring in 2022.

Details screen - return to position

Since a few weeks, Glide doesn’t keep the vertical scroll position anymore in my app. After viewing any item from an inline list, the app now always auto-scrolls back to the top. Before, Glide always remembered where I was vertically in my main app screen – which is obviously way better for the UX. I’m suddenly scrolling a whole lot more using my app. Is this related to a known bug? I didn’t find anything so far, hence I created a new one. Screen recording (mockup content): Dropbox - auto-scr…

Back button of details screen returns to the top of tab

Usually when scrolling through an inline list on a tab (list or details layout) if user goes to the details screen of that list item, on the back button the user is taken back to where they were on the tab. However some users report being taken back to the top of the tab which is very annoying when going through routine row by row tasks. Any idea why this could happen? Is it in our hands to help redesign or fix the app not to do this as I assume the default in Glide is for this not to happen.…

I tried the automated support with no luck. Is this a bug?

[nathanaelb]

It’s behavior that has not made it yet to the top of the pile of needed enhancements. Hopefully sometime soon

[Stryker]

Thank you for the reply. In my case it’s kind of a show stopper if I can’t return the user to where they were at in their work flow.

It appears that I can change the Item Click action to an Overlay navigation target to ensure that the user’s inline list position is held upon closing the overlay screen. I don’t see any ill effects from taking that approach.

Thanks, again!

[ThinhDinh]

An overlay doesn’t “reset” the underlying screen, that’s why when you close it, the underlying screen is still where it was.

If you navigate to another screen and come back, the current behaviour means it is fully reloaded and can’t remember where you were the last time.

[Stryker]

Makes sense to me now. Thank you!