navigation.js:173 Uncaught TypeError

[garrison0]

Still getting this error from links after updating to Gatsby 2.19.12. I've checked my dependencies and re-installed node modules.

I can recreate this issue by:

1. updating this starter
2. making a new root element implementing the router with '/' corresponding to 'index.js', '/foo' corresponding to the blog or some trivial page
3. putting a new link to the blog or some trivial page onto index.js and clicking it

navigation.js:173 Uncaught TypeError: Cannot read property 'getElementsByTagName' of null
    at navigation.js:173

>  170 | if (document.title) {
>  171 |      pageName = document.title
>  172 | }
>  173 | const pageHeadings = document
>  174 |     .getElementById(`gatsby-focus-wrapper`)
>  175 |     .getElementsByTagName(`h1`)
>  176 | if (pageHeadings && pageHeadings.length) {

See this previously closed issue, seems other people are still running into this aswell

[marcysutton]

Hi there, I got this to work with the latest Gatsby version by deleting the node_modules folder and package-lock.json (or yarn.lock) and then doing a reinstall.

[garrison0]

The problem persists for me in my environment.

I've deleted both node_modules and package-lock.json, reinstalled, and checked the dependencies. I've noticed gatsby-link still requires @reach/router 1.2.6 whereas gatsby requires 1.2.1. I'm not sure how relevant that is because the bug persists whether I important Link from gatsby, gatsby-link, or @reach/router.

Interesting if I build and serve, when I first try to load the link, it works, but afterwards I get the error in the devtools console.

If there's any other information I could provide, I'd be happy to

[arun-is]

@garrison0 what is the file name that you are using for the new page? Are you sure it matches that path that you are linking to? For example, did you make a foo.js and then link to /foo? I found if I make a Foo.js and then link to /foo, I see the error you are seeing

[garrison0]

@arun-is

that fixed the problem, thanks

but why wouldn't something like this work? :

...
import NewPage from './NewPage.js'

const App = () => (
    <Router>
      <Home path="/" />
      <NewPage path="/newpage" /> 
    </Router>
)

export default App;

[sidharthachatterjee]

Looks like the issue here is that page paths are case sensitive and hence it isn't able to find your page and breaks at this confusing spot (because it tries to announce the route change).

We should catch that before attempting this and redirect to 404.

[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! 💪💜

[jakubzloczewski]

I had similar problem as @garrison0 and I fixed it by following these instructions: https://www.gatsbyjs.org/docs/client-only-routes-and-user-authentication/#configuring-pages-with-matchpath

[nickwarters]

I've experienced the same issue, but only with some links. After trying a number of things I found it was only an issue with url paths with a capital letter in them. As soon as I switch them all lowercase they work fine.
To get around this, I have tried using a slugify function to convert all each everything to a lowercase URL in my Gatsby-Node but it doesn't seem to be wanting to play ball.

[nickwarters]

Okay ... I managed to fix it for me. I had pages which were created with slugified paths, however some of my links were pointing to un-slugified paths of the pages. Theoretically this should have just returned a 404 Page not Found however instead it threw this error.

Resolved for me now though.

[cmr624]

Having a similar issue, I am using Gatsby-Image, and reloading or hot reloads crash with the error.

How would I go about reverting to the correct version of @reach/router ? I have Gatsby installed, but no @reach/router in my package.json

[jlabs]

Having the same issue using the same starter template.

For me, removing the line <MDXRenderer>{post.body}</MDXRenderer> in src/templates/blog-post.js made all the pages under /blog load instantly. I'd not made any changes to the starter project up to this point (other than fixing all the errors OOTB). The content on each blog post page still loads, and there's no console errors. Yet.

-- EDIT --
It appears just using the tags <MDXRenderer></MDXRenderer> also breaks the page display

[jodiedoubleday]

I'm having the same issue but on the index.js page. When running Gatsby Develop I get the navigation.js error. Every other page is fine.

Seems to only happen when I use Gatsby Image/image sharp.

[Ir1d]

I'm having the same issue on certain page. There doesn't seem to be much difference between the pages. Also using image sharp
upd: but disabling sharp doesn't help

upd: I solved my issue. I found there was a \\ inside my frontmatter, and the str was used as key of some component. after setting some other things(ex: index) as key, the problem was solved.

Hint: I debugged this by running build (since the build was mostly correct and resulted minor error). Manually opening the corresponding html and in the console it told me that I had two strange things as key and there were duplicate(?? while actually it is not duplicate, but the problem was indeed in the keys)

[xanderios]

Had the same issue, not a Gatsby issue I guess:
What I did to debug that:

1. Commented every section of my homepage (the page that gave error on build);
2. Uncomment sections of homepage 1 by 1 until I find the one with error.

In my case it was a SwiperJS Instance that was removed between pages, and that was causing the error.

I read that some people installed some plugins and libraries and got the error, so I figured that my Swiper (but other libraries too) could bring the error. Hope it helps you guys.

[saadaouad]

Any update on this please? still getting the same issue using "gatsby": "2.20.9", version

[EliranGooner]

Still getting this error too.

Update:
Fixed it on mine by moving a download <a> to another place on the page.

[dannyvaughton]

I am also getting the same error on [email protected]

It appears to be when a is being used by one of my antd components. I can't remove these easily as they have been integral to my application.

Also, the error seemed to pop out of nowhere. One second it was working, the next not.

I have cleared the cache, removed node_modules & lock file. Not sure where to go from here.

[shicholas]

I've been getting this error too trying to create dynamic client-side routes using Reach Router (fixed to version 1.2.1 to address other comments in this thread.

I pushed #23196 as a potential fix to this nullcheck.

[BrooksPoltl]

I had this issue, and nothing else worked until I found out that slugs are formatted /article-name/ so I was creating a page for /topic//article-name/ by doing

createPage({
      path: '${post.node.frontmatter.topic}/${post.node.fields.slug}',
      component: blogPost,
      context: {
        slug: post.node.fields.slug,
        previous,
        next,
      },
    })

Which when you link to this page it will resolve to topic/article-name

[Hyraze]

This issue will be closed with this pull request #23196