Page Refresh Not retaining scroll position

[NubSoup]

Description

When i refresh a page with a scroll bar, after i have scrolled down, the page reloads but i am back at the top of the page, not at the same scroll position.

Steps to reproduce

Go to: http://gatsby-starter-default-demo.netlify.com/

shrink window down to ensure a decent amount of vertical scrolling. Hit refresh (note it sometimes works right away but once it breaks it's broken for good). If it didn't break right away do a few quick refresh spams and it should break

Expected result

hitting the refresh button takes me back to the same scroll position i was. (since i am not in a route i cannot use shouldUpdateScroll as it's not going through a route)

Actual result

page reloads at the top of the page, does not jump back even after waiting.

Environment

System:
OS: macOS High Sierra 10.13.6
CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 11.9.0 - /usr/local/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 6.5.0 - /usr/local/bin/npm
Languages:
Python: 2.7.10 - /usr/bin/python
Browsers:
Chrome: 73.0.3683.75
Firefox: 60.0.2
Safari: 12.0.3
npmPackages:
gatsby: ^2.1.31 => 2.1.31
gatsby-image: ^2.0.33 => 2.0.33
gatsby-plugin-manifest: ^2.0.24 => 2.0.24
gatsby-plugin-offline: ^2.0.25 => 2.0.25
gatsby-plugin-react-helmet: ^3.0.9 => 3.0.9
gatsby-plugin-sharp: ^2.0.28 => 2.0.28
gatsby-source-filesystem: ^2.0.24 => 2.0.24
gatsby-transformer-sharp: ^2.1.17 => 2.1.17
npmGlobalPackages:
gatsby: 2.0.116

[wardpeet]

It seems like an issue with scroll-behaviour package we use. We restore the original scrollRestoration value on page navigation but I guess when doing a lot of refreshes onbeforeunload does not have time to actually run code.

https://github.com/taion/scroll-behavior/blob/6bbb7f0d462a3c084a5b13758a7077f19d752a40/src/index.js#L44. we could create a PR to actually force it to auto instead of the last value.

[NubSoup]

@wardpeet, Thanks for looking into this. i didn't go deep enough into the packages it seems.

This problem is also not only against quick refreshing, but first page load to first and only reload. I am able to start up a clean new gatsby starter project locally. Load the home page in browser, resize it, scroll, refresh once and see that it's not retaining the scroll position.

I did some quick console debugging and i'm not so sure it's with the scroll-behaviour component. I only found the plugin being referenced in the gatsby-react-router-scroll piece. I see it being initialized on load but not doing anything else. i only get other logging to work when i'm going from one page to another using the gatsby link.

That's as far as i have been able to get today, i'll try and see if i can get more time to debug tomorrow.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[narration-sd]

Do not close, kindly! This is important here, and no doubt to many.

I've seen there are people who want lose-the-scroll-and-show-me-page-top, but would be confident there are lots of applications where scroll memory is intrinsically important. We should always be able to have both, no?

As well, this auto-close seems very much too quick on the draw...4 days??? How about 4 months, not that anything should go on that long....bots...

[narration-sd]

see #12997 (comment)

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[narration-sd]

This should stay open due to @wardpeet 's work on it, no?

And here's #12997 (comment) a progress I had to make from actual use in the field.

This can possibly help guide, as there's both a current workaround for those of us who got a surprise, and a suggestion how this functionality should really be made available, with flexibility to the actual range of use cases.

There's also appreciation for what @pieh did to control the dangers of what's really at the heart of trouble here -- an approach that should be taken for revisions also, one would suspect...

Cheers, fellows.

[wardpeet]

sorry for the late response but let me create a PR on the package. The problem with moving it back to javascript means scroll restoration will be slow so that's why we want to provide on the browser.

@narration-sd do you have a test case were scroll restoration doesn't work? I just tested again with the starter and i have no issues. Make sure to run in on production mode.

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[vincezun]

I thought It was broken because I'm testing it in dev mode until I read wardpeet comment and It works perfectly even if you spam refresh.

[narration-sd]

@wardpeet Sorry, I seem to have overlooked email notification on your message above.

• what I was doing was in production build, but the tip that it doesn't work in dev mode is surely valuable.
• why it doesn't work may be due to something I noticed, that the scroll values appear to be saved according to a constant key 'initial' for most pages, but according to a constantly changing numeric key for home pages.
• in the home page case, then ,you get a different key every time if you refresh, so it's hard to imagine it's going to work to recall scroll, though I didn't investigate further. That key comes from the browser history mechanism. All of this is consequent of the update to 'use location.key for scroll behaviors' a couple of months ago, that set off my arrangement's problems.
• as mentioned, the system I'm building isn't typical for Gatsby, and I wasn't using scroll memory in the expected way. I've since replaced with my own scroll memory, so no more issues here, thanks.
• I kind of wonder about normal Gatsby behavior, but that's perhaps ok even with the odd basis I seem to find? Indeed, 'location.key' isn't used except for the no-router-path home page, it seems. And then, the question of the constantly changing key values on home page refresh appears, but maybe that's ok?

@vincezun glad you commented - I wonder if your home page and your other pages all work, based on what I found internally? Also if you retain scroll position on multiple home page refreshes, though I think you would on non-home pages, if it works on those at all... Speed of refreshing should have no effect from this behaviour I mention, as a note.

[wardpeet]

in the home page case, then ,you get a different key every time if you refresh, so it's hard to imagine it's going to work to recall scroll, though I didn't investigate further. That key comes from the browser history mechanism. All of this is consequent of the update to 'use location.key for scroll behaviors' a couple of months ago, that set off my arrangement's problems.

Sorry but I do not understand what you mean. Are you saying that we don't have a unique key per page but rather per page view?

[narration-sd]

Certainly seemed so, when I had debug going on this.

I think you do understand what I meant to say...just will remind/clarify this happens only on the home page, with no pathinfo. For other pages, what I was getting was always 'initial' as key.

I discovered for sure by constantly dumping the whole window.sessionstorage, where you could see all these keys.

I don't remember now if I tested outside my special use, but don't think it matters for this. You should be able to see by refreshing in a normal Gatsby setup, and again dumping the window.sessionstorage. Doing this after each refresh, home page or pathed page will allow to see difference/form of results.

A very long day ending here, so hope this helps.

[vincezun]

In chrome & firefox: It works perfectly but if you go on inspect element and use responsive mode(phone), it is broken.
In edge, both.

[narration-sd]

Ok, @wardpeet & @vincezun ,

• I ran up a fresh gatsby-cli new project, and added some lorum ipsum to both pages.
• did a build and pushed to a website -- yes, scroll positioning doesn't work in develop...
• tried refreshes, back button or equivalent, and link-back for both pages.
• did this on main player browsers, Chrome & Firefox, Win10 1903 and Android 7.1.1 good phone

Results:

• scroll position recovered properly for refreshes and back/forward buttons, in all cases
• multiple refreshes on Home page indeed did not have a problem
• back or forward (sometimes) buttons equally recovered scroll
• link-backs (e.g. return to Home) always snap to top of page, rather than a recovered scroll position

Conclusions:

• I guess this is the default behavior you want, no? And that vocal community set.
• I guess what I observed as far as windows.sessionstorage content supports this, after all.
• as said, my needs are different, and I built my own scroll management to provide

So I think this issue is done, from my end.

[I complained here but have edited out a basic Gatsby issue, now reported as #14800 -- it actually was as first mentioned, and I apologize for emails you may have received as I dithered about that...]

Thanks for your attention, @wardpeet. Appreciated.

[narration-sd]

p.s. rereading some above, I did one more test -- hammered Cntl-R on the home page. Eventually, scroll memory came unstuck so I got top of page. Thus it's probably as you suggested above, @wardpeet, that onbeforeonload can be beaten if you try hard enough (this test on Chrome Canary).

It doesn't seem an important issue, but can mention I had something obscure recently that was helped by using onunload rather than onbeforeunload as the triggering event.

I think this situation also had to do with rapid page refresh/content switching (automatic), so maybe the idea could help here, if you can get and connect the info you want for scroll memory at this event time.

[stevefrench39]

Is there any new information or workarounds on this? My page programmatically reloads to demo a product and losing the scroll position is a big pain point.

Looks like the OP's http://gatsby-starter-default-demo.netlify.com/ isn't broken anymore but my site is still experiencing the problem on Gatsby v2.17.15.

I'm using the following plugins. Anyone still seeing this issue?

gatsby-plugin-sass
gatsby-plugin-remove-serviceworker
gatsby-plugin-react-helmet
gatsby-transformer-sharp
gatsby-plugin-sharp
gatsby-plugin-sitemap
gatsby-plugin-manifest
gatsby-plugin-paddle

[sergeylukin]

+1 having same issue, also sessionStorage is not populated on my website. v2.18.21

[Vacilando]

Gatsby:

• Gatsby CLI version: 2.9.0
• Gatsby version: 2.19.7

Browser:

• Chrome

Scroll position retained on page reload after build ✓

Scroll position NOT retained on page reload in develop mode.

My test:

• gatsby new gatsby-starter-default https://github.com/gatsbyjs/gatsby-starter-default
• cd gatsby-starter-default
• gatsby develop
• navigate to http://localhost:8000/ -> make a little browser window, scroll down, hit CTRL-R
• after reloading the scroll is not retained (we see the top of the page)

[lcfd]

Scroll position NOT retained on page reload in develop mode.

Same and also when the user refreshes multiple times the page scrolls down

[wardpeet]

Oh we're talking about develop? It's normal for develop to not support it. When a page is loaded it starts from an empty page and only creates the HTML through javascript. So on pageload there is no HTML to jump too.

If it also occurs during a live site with gatsby build then it's a bug.

[Vacilando]

Only in develop indeed.

Is there a place that clearly lists such differences between build and develop? There are quite a few of them and some may not be obvious to all of us. At least until after Gatsby is able to provide exactly the same behaviour in develop and in build (I think there's an issue about that somewhere).

[wardpeet]

There are only a few, this is what I can think of out of my head:

1. Page is only built client side so no server-side-rendering (think of it as client-only routes
2. Hot module reloading is on, when you do a change, your browser changes without a refresh
3. Stylesheets aren't created, <style> tags are injected

I'll be closing it again :)

[lcfd]

If it also occurs during a live site with gatsby build then it's a bug.

Our site is in production so it's happening with gatsby build.
Here → https://belkadigital.com/

After a few quick page refresh, begins to scroll down. Maybe it can help.