ViewPort issue on previously visited page

[basile-henry]

trafficstars

I noticed a weird issue with the scroll position when visiting the pages of packages from the home page. It looks like the current scroll position is being kept through to the next page. But this only happens when that next page has been visited before (in the same session).

I have noticed the same behavior on Chrome (Linux), Chrome (Android), and Firefox (Linux).

Quick steps to reproduce:

1. Open https://package.elm-lang.org in a new tab/browser
2. Scroll down to elm/parser such that the scroll position isn't at the top of the page
3. Click on the elm/parser page (this should be a normal scroll position, i.e at the top of the page)
4. Go back to the home page either by pressing back or the home button (top left)
5. Repeat step 2 and 3 (scroll down to elm/parser and click)

The second time around the scroll position is kept from the home page to the package page instead of going to the top of that page.

Note: I chose elm/parser because it has a long landing page that requires scroll (that might not be the case on a vertical monitor, small zoom)

I believe this behavior is unlikely to be intentional. Tell me if this has already been reported somewhere else (I couldn't find any issues about this here) or is already being worked on.

I can have a look at the code base and see if I can make a PR to fix this! :smile:

By the way, congratulation of Elm 0.19 :tada: Great work, it looks awesome!

[basile-henry]

Alright, I've had a closer look at the source code. But I have unfortunately not been able to build frontend/backend locally to test my ideas.

I think the issue is around here: https://github.com/elm/package.elm-lang.org/blob/master/src/frontend/Page/Docs.elm#L110

The use of the function scrollIfNeeded in getInfo seems to only occur when the readme and docs are in the current session. This would correspond to the bug only appearing after the first time a page is visited (when it is already loaded into the session).

Having a closer look at scrollIfNeeded, it seems to be using the tag of an element that is in focus. Could that tag be leaking from one page to the next? And hence result in a scroll update even though that tag lookup should have failed?

I'm just throwing a few ideas, hopefully it's helpful! :smile: