Console log shows the wrong destination file

[QJerryxjh]

in my browser console, log info go wrong, it should show real console.log file and correct line info, but now it always show "react_devtools_backend.js: 4049", link to source code show warning:
"Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

• Move data fetching code or side effects to componentDidUpdate.
• If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
• Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.
  Please update the following components: %s"
  when i disable react developer tools, it goes correctly. but it goes wrong in 4.18.0 react developer tools. and my colleagues' chrome with react developer tools 4.17.0 is right

Note from maintainers: #22257 (comment) is a workaround until this is fixed in React DevTools

[gaearon]

Can you try clicking the arrow to the left of the message? It should expand the full stack which gives you precise location of every frame including the one you’re looking for.

Also please show the screenshot of your DevTools settings.

[QJerryxjh]

@

[QJerryxjh]

@gaearon sry, it looks like i have a wrong devtools setting,thank you for you help

[mattywong]

Hey @gaearon, we seem to also be getting this issue on regular console logs (sourcemaps mapping to react_devtools_backend.js:4049). When the react devtools extension is disabled, sourcemaps show correctly. Webpack devtool is set to 'eval-source-map'. This seems to have happened quite recently as I don't recall seeing this before. Let me know if you need me to provide any other info.

Left: incognito with react devtools disabled, Right: with react devtools enabled

[gaearon]

Not sure if anything changed here but reopening just in case.

[keul]

I can confirm: it seems that every console.something is captured by the extension.

[bvaughn]

Chiming in here to confirm that this reported behavior is intentional– although I understand the confusion or annoyance. 😦

The "problem"

As of the version 18 release, DevTools always overrides the native console to either dim or suppress StrictMode double logging. (Before it only did it if you enabled a feature like component stacks.) DevTools also now overrides console.log (for double logging) so it's more noticeable. (Before it only overrode console.error and console.warn– to add component stacks.)

The major unfortunate drawback of this overriding is that it changes the location shown by the browser's console as reported in this issue. I requested better tooling support from browsers a couple of years ago because of this, but there hasn't been any action unfortunately: whatwg/console#163

There is a related tc39 proposal but I don't think it has made any progress since then.

A possible solution

One possible change we could look into making on the DevTools side to improve this default experience is to only patch console methods during StrictMode double render. (Even if other features like component stacks are enabled, we wouldn't have to override the console.log method.)

Right now the way this works is that DevTools eagerly patches the console APIs, and asks React to check if StrictMode is active to know if it should also dim or suppress. Perhaps we could change this so that React called a DevTools API instead to notify when double rendering started, and then DevTools could only patch console.log during a double render.

cc @lunaruan

[mattywong]

Perhaps a setting could be added to devtools to opt in to this new behaviour (or opt out)? Atleast till theres a way to fix both? Tbh i had no idea of the double logging issue or maybe had just never noticed it, and I would assume others would be in the same boat. The source map line change however is definitely noticeable and arguably a much more annoying issue (imo)

[gaearon]

Yes, we understand why the issue is annoying and will look into some way to resolve it.

[jzombie]

This is awesome. I browsed the issue list, looking just for this, saw it as the first issue, subscribed to it while ago, and now saw the latest reply from @gaearon.

[allengordon011]

I've found a workaround using console.info instead of console.log. I hope that's helpful

[jzombie]

For what it's worth, I've found that by doing things like this [example below], it allows you to override the console with a prefixer while retaining the original stack trace. Not sure if that could be of any relevant help here, but I'm using it in a project for a custom logger, because I found that most logging overrides screw with the stack trace.

console.log = Function.prototype.bind.call( console.log, console, "some-logging-prefix" );

[bvaughn]

@jzombie That's a nice tip, but I don't think that offers a way for us to do anything more than inject a static parameter, does it? (I don't think it offers a way to run code, like we're doing in this case.)

[jzombie]

@bvaughn I've only used it to inject a static parameter, but perhaps it could run some code with a bit of fiddling.

[jzombie]

i.e. maybe if you used some sort of object property getter to render the string, and ran the code inside the getter... ?

[bvaughn]

If you have any example code/idea you could share, we'd be happy to take a look. 😁

I think a getter would be evaluated at the time you define the call binding, rather than at the time you called the console method...but maybe you have an idea? :)

[jzombie]

I tried a couple of different approaches because I was really hoping it would work, and couldn't get beyond the initial value.

I'd love to pursue this, this afternoon, but my job would probably not be happy about it, because it's completely unrelated to what I'm supposed to be working on.

[bvaughn]

As a temporary workaround for folks affected by this, you might try adding the react_devtools_backend.js script to the browser's "ignore list":

[vzaidman]

In Chrome, a workaround would be adding the script that overrides the console to the "ignore list" (right-click on the script in dev-tools and add to ignore list).

It has some drawbacks, because "ignore list" does a little more than just that, but it works nicely for me for now.

[JuraJuki]

Any updates on this issue?

[jzombie]

@bvaughn I experimented a little and this is the closest I could get to make something work, where each call to console.log would call alert() with a new index, while retaining the original stack trace.

Maybe it could be useful, or maybe not.

<script>
  // Original console log
  const oLog = window.console.log

  const console = {
    // Inherit window console
    ...window.console,

    idx: -1,

    // Overridden console log
    get log() {
      // Alert idx on each log call
      ++this.idx;
      alert(this.idx)   

      // Return original console log with original stack trace
      return oLog
    }
  }

  console.log("hello"); // alert(0); console.runner.html:22
  console.log("hello"); // alert(1); console.runner.html:23
  console.log("hello"); // alert(2); console.runner.html:24
</script>

(The "inherit window console" thing is not used, but was just seeing if it could be used like this w/o error.)

[jzombie]

One more example showing the console log message, itself, changing per call.

<script>
  const console = {
    idx: -1,

    // Overridden console log
    get log() {
      ++this.idx;

      // Return original console log with original stack trace
      return window.console.log.bind(window.console, `Iteration: ${this.idx}`);
    },
  };

  console.log("hello"); // "Iteration: 0 hello"; console.runner.html:14
  console.log("hello"); // "Iteration: 1 hello"; console.runner.html:15
  console.log("hello"); // "Iteration: 2 hello"; console.runner.html:16
</script>

[gaearon]

@JuraJuki If there were updates on this issue, they would be… on this issue. Please refrain from comments like this — they create notification noise for other people and don’t bring the conversation forward.

There’s ongoing work on this. When it’s done we’ll close the issue.

[EricRabil]

Another option to work around this without disabling the backend is to Object.freeze(console) - this is not a long-term fix but does let you keep the other parts of the backend.

[jzombie]

I find it really ironic that the very same people who created this amazing library, and then also make the underlying functionality which drive hooks, can't wrap the browser console and not lose the stack trace.

Perhaps, just don't wrap the console at all, or find a library that does it and use it instead?

[bvaughn]

The solution described above:
#22257 (comment)

Was released yesterday with DevTools version 4.19.0:
https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4190-september-29-2021

[guncha]

If you agree that this is an issue when it happens all of the time, why would you change it so that it only happens some of the time?

[bvaughn]

@guncha Your comment is missing some important context:

1. There is no way to tap into the console API and add information without triggering this observable effect. It's unfortunate but no browser API exists for this.
2. StrictMode double console logging has long been controversial (see Community feedback on console silencing #21783). Overriding the console to dim or hide the second logged message (Console Logging for StrictMode Double Rendering #22030) is the best compromise we've been able to come up with.

[petetnt]

Any ETA for 4.19. (or 4.19.1.) landing to the Chrome web store?

[bvaughn]

No. I have no insight into Chrome's review process.

[petetnt]

@bvaughn that's understandable, no worries. Thanks for your hard work, React Dev Tools is an invaluable tool ❤️

[bvaughn]

4.19.0 is finally through review which unblocks 4.19.1 from being submitted. (Not sure how long it will take them to approve it.) I'm on PTO today b'c it's my birthday but I've asked if someone else on the team would submit it.

[yairEO]

still happens in version 4.22.0

[gaearon]

@yairEO

What exactly "still happens"? This is not a helpful report because we don't know which part you're referring to.

I have verified that the extension does not clobber the log location for the first render. It does clobber the location for the second render in React 18, but that's expected. Hopefully the first location should always be enough.

I am going to lock this issue to avoid confusion. The original problem has been resolved. If you see a problem, please file a new issue.