Bug: devtools: throws JSON.parse exception.

[Iipal]

React version: ^17.0.1

Steps To Reproduce

1. it's just starts throwing error, and i do not remember is this was before.

I'll be glad to give you more info but i don't know where to search for any about this.

[ronin-c]

waho

[eps1lon]

It doesn't look like this bug report has enough info for one of us to reproduce it.

Please provide a CodeSandbox (https://react.new/), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.

Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve

[bvaughn]

I'll be glad to give you more info but i don't know where to search for any about this.

@Iipal Information that would be helpful:

1. Which browser and version are you using?
2. What operating system are you using?
3. Which version of DevTools do you have installed?
4. Which website(s) do you see this error on?
5. Have you tried restarting your browser/computer to see if the error is fixed?

[Iipal]

@bvaughn

1. tested in Google Chrome (87.0.4280.88 (Official Build) (64-bit)), and Firefox 83.0 (64-bit)
2. Windows 10 20H2 (build 19042.630)
3. 4.10.1 on both Chrome and Firefox
4. localhost, on dev.server, but after build with react-scripts build this error disappear
5. yes, and no it doesn't fix it

[bvaughn]

localhost, on dev.server, but after build with react-scripts build this error disappear

@Iipal To be clear, this only happens for you on your local host? and only before you run the build command?

[Iipal]

@bvaughn yes

[bvaughn]

Okay so what's happening here is this:

DevTools overrides the console.warn and console.error messages so that it can add information about the current React component (if one is rendering). It does this to help you find where in your React app an error or warning is coming from, e.g.

Not all errors/warnings are related to React though. For example, the one you are reporting is not. But because DevTools overrides the console method, the browser console displays the error as though it was coming from DevTools rather than the actual call sight. This is kind of unfortunate but I don't know of a way to work around this.

This problem is discussed in more detail (along with my wish for a better API) here if you're curious:
whatwg/console#163

[Iipal]

@bvaughn okay, i understood, something. But there is another problem what i just discovered. after this happened the Components tab in browser devtools doesn't work too :c
UI is rendering good, but components hierarchy doesn't appear at all

[mntnoe]

I am experiencing the same issue, and I think it may actually be an issue with React Devtools.

My component hierarchy is missing as well. Setting a breakpoint shows the following:

It looks like an empty string has been saved instead of null or an object, for the last selection.

[bvaughn]

@mntnoe Any idea how to repro this (the initial saving of an empty string?)

Regardless, any interest in submitting a fix?

[mntnoe]

@bvaughn Hmm, looking at the source code, there is only one place where React::DevTools::lastSelection is set in sessionStorage, and it's always an object:

https://github.com/facebook/react/blob/master/packages/react-devtools-shared/src/backend/agent.js#L749

Maybe it is an issue from Firefox Sync?

I was able to fix the problem locally by removing the item:

sessionStorage.removeItem('React::DevTools::lastSelection')

The faulty state can be reintroduced like this:

sessionStorage.setItem('React::DevTools::lastSelection', '')

As remembering the last selection is not a critical feature, we could consider surrounding JSON.parse with a try/catch. This will allow the remaining code to run.

if (persistedSelectionString != null) {
  try {
    this._persistedSelection = JSON.parse(persistedSelectionString);
  } catch (e) {
    /* log warning */
  }
}

The storage item will be written (and corrected) again next time something is inspected by the user.

[bvaughn]

Yeah, it's not clear how it go corrupted but it seems unfortunate that we don't recover gracefully. So catching and logging a warning (and also clearing the corrupt storage) would be good.