Page refresh loses hashes after service worker update

[ediblecode]

Description

I'm linking between pages using a hash to link to a specific section. After a site re-deploy, which I think in turn triggers a service worker update, the page reloads after navigation and loses the hash. Which in turns mean a user isn't taken to the section related to the link they clicked.

From digging around, I think it's caused by this:

gatsby/packages/gatsby/cache-dir/navigation.js

Lines 68 to 73 in 2a72ec1

	// If we had a service worker update, no matter the path, reload window and
	// reset the pathname whitelist
	if (window.___swUpdated) {
	window.location = pathname
	return
	}

Where the ___swUpdated comes from:

gatsby/packages/gatsby/cache-dir/register-service-worker.js

Lines 27 to 30 in 2e6825a

	// We set a flag so Gatsby Link knows to refresh the page on next navigation attempt
	window.___swUpdated = true
	// We call the onServiceWorkerUpdateReady API so users can show update prompts.
	apiRunner(`onServiceWorkerUpdateReady`, { serviceWorker: reg })

.

I think I might be able to work round it by using onServiceWorkerUpdateReady to reload the window myself (keeping the hash), or by setting window.___swUpdated = false like this blog post. But this seems wrong to have to do this, when the default behaviour is to refresh after an update - it feels like navigation.js should reload the page, and keep the hash. Maybe by using window.reload(true) rather than setting window.location?

-window.location = pathname
+window.reload(true)

Steps to reproduce

1. Add gatsby-plugin-offline to a new gatsby site
2. Create a site with 2 pages, page1.html and page 2.html
3. Add link (using gatsby Link) from page1.html to page 2 with a hash e.g. page2.html#a-section
4. Build the site
5. Navigate to page1, click the link to page 2
6. Make a small code change and build the site again
7. Navigate to page1, click the link to page 2

Expected result

The page reloads, because of a service worker update, with the same URL, including the hash.

Actual result

The page reloads, but excludes the hash and just uses the pathname.

Environment

n/a

[ediblecode]

This is kind of related to #25778 in a way as they're both dealing with hashes in links. Just in case anyone else has issues using hash links...

[madalynrose]

I'm sorry you're running into this issue @ediblecode! Thanks for lettings us know! It would be really helpful if you could provide a minimal reproduction. I'm tagging in @moonmeister who might have more context on gatsby-plugin-offline and service workers but it'd be easiest for us to help debug if we could see a live reproduction of the issue in something like codesandbox.

[ediblecode]

Thanks for the reply. I did think about a minimal repro but it's pretty tricky as it requires a build, after you've visited the site so you can revisit, with a different build hash so the service worker updates, which is when you'd see the refresh. So not that straightforward I'm afraid unless there's another way? Although I could set up a minimal repro repo if that's easier?

…

On Tue, 21 Jul 2020, 20:38 Madalyn, ***@***.***> wrote: I'm sorry you're running into this issue @ediblecode <https://github.com/ediblecode>! Thanks for lettings us know! It would be really helpful if you could provide a minimal reproduction. I'm tagging in @moonmeister <https://github.com/moonmeister> who might have more context on gatsby-plugin-offline and service workers but it'd be easiest for us to help debug if we could see a live reproduction of the issue in something like codesandbox. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25889 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG2F3DE32CKYWWZ6IBDMILR4XVBPANCNFSM4PCX4QSA> .

[ediblecode]

Ok, I've create a minimal repro repo, see https://github.com/ediblecode/gatsby-hash-repro.

1. Git clone
2. npm run build
3. npm run serve
4. Open localhost:9000
5. Click the link to page 2 - the url should still contain #test
6. Stop the serve command, and make a simple content change to any file
7. Repeat steps 2-5 only this time page2.html will reload and lose the hash

There must be a build hash used somewhere for the service worker as you need to make a content change to see trigger a service worker update.

I hope that helps @madalynrose and @moonmeister but more than happy to add more details/screenshare to demo if needs be.

[wpj]

There may be other aspects to this that I haven't considered, but I think setting window.location to the original value of to passed to the navigate function instead of the parsed pathname would fix this:

gatsby/packages/gatsby/cache-dir/navigation.js

Line 49 in 83926c8

const navigate = (to, options = {}) => {

[ediblecode]

I think you're right @wpj. I initially thought window.reload(true) would do the trick but that would reload the current page rather than the destination page, so you're right that this makes more sense:

-window.location = pathname
+window.location = to

I did wonder if this wouldn't work if there was a prefixed path (sub folder) but looks like the prefixing is done in gatby-link itself:

gatsby/packages/gatsby-link/src/index.js

Line 196 in 693d4aa

const prefixedTo = rewriteLinkPath(to, location.pathname)

so by the time it get's to navigate then it's already prefixed, so just using to seems sensible to me.

[github-actions]

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/contribute for more information about opening PRs, triaging issues, and contributing!

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

[ediblecode]

Definitely not stale

[Auspicus]

@ediblecode Don't know if this is still an issue for you but #32323 should address the issue. It also handles query parameters getting dropped which was the bug we had that caused us to look into this.