Preserve scroll position when using the back to search results link

[sarayourfriend]

Problem

The "scroll to top" behaviour happens every time you use the back to results button. This does not follow the standard behaviour of back/forward navigation in the browser where page scroll position is preserved. It does work with the browser back/forward button, so the back to results button should mirror that behaviour.

To fix this, the back to results button should be implemented using standard browser back button when possible.

Implementation

• 🙋 I would be interested in implementing this feature.

[zackkrida]

Update: the browser back/forward buttons appear to be working correctly here, but our "Back to results" link on single images does not:

[devinmaeztri]

I'm using Openverse this morning, searching for about 7 topics. If I clicked on an image then wanted to go back to look for more images, I clicked on the Back to results button, but every time it would bring me to the top page position. It means I had to scroll down again to go back to where I was at.

Just now I tried again searching for cats and experienced the same behavior.

[sarayourfriend]

Thanks for sharing your experience with this bug @devinmaeztri.

I've updated the labels to reflect that this is an accessibility issue, as we're breaking the expected behaviour of the browser in an interface item that technically duplicates built-in browser features. They should behave the same. I've also added the help wanted label, escalated the priority to medium (particularly as the issue has been open for a long time) and moved it into our todo column of issues to tackle within the next few weeks.

[devinmaeztri]

Thank you @sarayourfriend!

[AetherUnbound]

We discussed this during our priorities meeting today - ultimately this issue would be addressed by way of moving the individual search results into a model (#429). However, an implementation with our current framework could be quite complex, and @obulat and @dhruvkb expressed that there might be additional concerns about having to adjust the implementation significantly after upgrading to Nuxt 3 (#411). If I'm incorrect about the potential complexity around implementation here please let me know!

@devinmaeztri thank you again for re-raising this and we will address this issue as soon as we can!

[sarayourfriend]

Vue-router doesn't support this behaviour, it turns out: vuejs/router#1189 (comment)

It's computeScrollPosition function, which it uses to decide where on the page to scroll to after navigating forward/back, always uses window.pageXOffset and window.pageYOffset, and this is not configurable.

https://github.com/vuejs/router/blob/main/packages/router/src/scrollBehavior.ts#L71

I don't think solving it would change very much between Nuxt 2 and 3 because the problem is fundamentally in vue router. I'd like to take a quick, time-boxed attempt at this, because as I said, I think the issue will persist, and the single result modal is (a) blocked and (b) almost certainly far more complex than this issue...

The recommended implementation in the vue router issue I've linked is to save the position ourselves and manually scroll the element. I think this is doable, but maybe I'm totally wrong.

@dhruvkb @obulat can y'all elucidate your concerns over needing to change the implementation for nuxt 3? Have y'all found something about the implementation of Nuxt 3's routing that makes it significantly different from vue router's behaviour in Nuxt 2? As I understand it, we'd need to save the scroll position of the search results element and then retrieve it when the page loads. Would that kind of thing be super different between Nuxt 2 and 3?