Searching your project for a property named in an error is often inconclusive. The failing code may be minified, bundled, loaded from a dependency, or injected by a browser extension. Start from the filename and call stack that the browser recorded, not from the error text alone.
Last updated: October 2, 2026.
window.addEventListener('error', (event) => {
console.table({
message: event.message,
file: event.filename,
line: event.lineno,
column: event.colno
});
});
window.addEventListener('unhandledrejection', (event) => {
console.error('Unhandled promise rejection:', event.reason);
});Add these temporary listeners early in application startup when an intermittent failure is difficult to reproduce. They provide context, but the DevTools stack still gives the best path back through the functions that led to the exception.
Follow the call stack and script URL
In Chrome DevTools, enable Pause on uncaught exceptions in the Sources panel and reproduce the problem. When execution pauses, inspect the Call Stack. Select each frame to move to its caller, and enable Show ignore-listed frames if third-party frames are hidden. Chrome’s JavaScript debugging reference documents these controls.
Look at the script URL. Your own domain usually points to application code; a CDN points to a dependency; and a chrome-extension:// or extension:// URL identifies an extension. Test in a private window with extensions disabled before changing your application.
Restore original names with source maps
If the frame opens a compressed bundle, verify that production source maps are available and match the deployed build. Chrome can map generated lines back to authored files and shows loading failures in Developer Resources. Its source-map guide explains the workflow.
Once you find the first frame belonging to your code, inspect the value immediately before the failing property access. Review JavaScript functions, variables and scope, and what JavaScript can do for the language concepts behind the trace.
