Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

logCapturedError ate our error message #16605

Closed
Jack-Works opened this issue Aug 29, 2019 · 6 comments
Closed

logCapturedError ate our error message #16605

Jack-Works opened this issue Aug 29, 2019 · 6 comments
Labels
Resolution: Needs More Information Resolution: Stale Automatically closed due to inactivity

Comments

@Jack-Works
Copy link
Contributor

Do you want to request a feature or report a bug? Bug

What is the current behavior?
image

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:

Our application is run in a very complicated environment. It's hard to do that.

What is the expected behavior?
I change the bundled file, add console.error(error) in logCapturedError

And the correct error and it's stack is printed.

image

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
I'm debugging in Firefox Developement Edition. And the code is running in the WebExtension environment. Please consider if the following code is correct in Firefox

// Browsers support silencing uncaught errors by calling
    // `preventDefault()` in window `error` handler.
    // We record this information as an expando on the error.

    if (error != null && error._suppressLogging) {
      if (errorBoundaryFound && willRetry) {
        // The error is recoverable and was silenced.
        // Ignore it and don't print the stack addendum.
        // This is handy for testing error boundaries without noise.
        return;
      }
      // The error is fatal. Since the silencing might have
      // been accidental, we'll surface it anyway.
      // However, the browser would have silenced the original error
      // so we'll print it first, and then print the stack addendum.
      console.error(error);
      // For a more detailed description of this block, see:
      // https://github.com/facebook/react/pull/13384
    }
@threepointone
Copy link
Contributor

It's hard to comment further without a reproducing example. Could you try to reproduce just the error in a new isolated project, and see if the problem persists?

@Jack-Works
Copy link
Contributor Author

I figured it out. It's a Firefox bug.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1469304

@Jack-Works
Copy link
Contributor Author

manifest.json

{
    "$schema": "http://json.schemastore.org/chrome-manifest",
    "name": "Debugger test",
    "version": "1.5.3",
    "manifest_version": 2,
    "permissions": ["http://example.com/*", "webNavigation"],
    "background": {
        "scripts": ["/background.js"]
    },
    "content_scripts": [{ "matches": ["http://example.com/"], "js": ["/react.js", "/react-dom.js", "/content.js"] }]
}
function App() {
    throw new Error('Render failed')
}
ReactDOM.render(React.createElement(App), document.body.children[0])

@Jack-Works
Copy link
Contributor Author

This bug caused by Firefox will not show error in a content script nither emit a window.onerror event

@Jack-Works
Copy link
Contributor Author

Please consider disabling the "pause on exception" preservation for Firefox content script. (Can be detected by "browser" in globalThis && globalThis !== window)

@stale
Copy link

stale bot commented Jan 10, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Needs More Information Resolution: Stale Automatically closed due to inactivity
Projects
None yet
Development

No branches or pull requests

2 participants