Cross-origin error handling in DEV (#10353)
* Add DOM fixture for cross-origin errors * Use a custom error object in place of cross-origin errors Cross-origin errors aren't accessible by React in DEV mode because we catch errors using a global error handler, in order to preserve the "Pause on exceptions" behavior of the DevTools. When this happens, we should use a custom error object that explains what happened. For uncaught errors, the actual error message is logged to the console by the browser, so React should skip logging the message again. * Add test case that demonstrates errors are logged even if they're caught * Don't double log error messages in DEV In DEV, the browser always logs errors thrown inside React components, even if the originating update is wrapped in a try-catch, because of the dispatchEvent trick used by invokeGuardedCallback. So the error logger should not log the message again. * Fix tests * Change how error is printed in DEV and PROD In DEV, we don't want to print the stack trace because the browser already always prints it. We'll just print the component stack now. In PROD, we used to omit the JS error message. However we *do* want to show it because if the application swallows the error, the browser will *not* print it. In DEV it works only because of the fake event trick. So in PROD we will always print the underlying error by logging the error object directly. This will show both the message and the JS stack. * Make the wording tighter and emphasize the real error is above There's a few goals in the rewording: * Make it tighter using line breaks between sentences. * Make it slightly less patronizing ("You should fix it" => "You can find its details in an earlier log") * ^^ This also helps highlight that the real error message and stack is above * Group subsections: intro (there's an error), component stack, and final addendum about error boundaries * ^^ Otherwise people might think error boundaries are part of the reason they have an error * Make it clear "located at" is not the stacktrace. Otherwise it feels confusing. This makes it clearer you should still look for stack trace (with other details) above and introduces the concept of component stack. * Make the message shorter * Unused variables * Fix an error caused by fixing lint * One more bikeshed * Fix fixture * Remove unused file * Concise wording * Unused variables