Should I include console warnings in a bug report?

Include warnings only if they appear at the exact moment the bug occurs — for example, a React 'key' warning on a list that's rendering incorrectly. Background warnings that appear on every page load (deprecation notices from third-party scripts, extension injections) are noise — don't include them.

What does 'Uncaught TypeError: Cannot read properties of undefined' actually mean?

It means your code tried to access a property on a value that was undefined — e.g., calling .map() on null, or accessing response.data.user when response.data was empty. The stack trace below the error tells you exactly which file and line. Include the full error message AND the first 3 lines of the stack trace in your bug report.

How do I tell if a CORS error is a real bug or a staging config issue?

Check if the CORS error appears in production too. If it only appears in your staging or localhost environment, it's almost always a missing CORS header in your staging server config — not an application bug. If it appears in production, it's an API configuration bug worth filing immediately.

What's a CSP violation and why does it matter?

A Content Security Policy (CSP) violation means your app tried to load a resource or execute code that violates your security policy. These appear as 'Refused to load/execute...' messages. They matter because they're either a genuine misconfiguration (a broken feature for users with strict CSP) or a sign that something is injecting code where it shouldn't — both are worth a bug report.

Browser Console Errors: Signal vs. Noise in QA Triage

Open the console on most production web apps and you'll find a wall of messages: deprecation warnings, third-party analytics errors, extension noise, CSP violations, and the occasional genuine application error mixed in. For someone filing a bug report, the question is always the same: which of these actually matter?

The answer has a structure. Once you know it, reading a console for relevant errors takes less than two minutes.

Step one: filter to Errors

In Chrome DevTools, the console default shows All levels: errors, warnings, info, and verbose. Click the dropdown next to the filter box and select Errors only. This eliminates roughly 80% of the noise before you read a single line.

If no errors appear after filtering: good news — the console isn't showing you the bug. Look at the Network tab instead.

The error types that always matter

Uncaught TypeError and Uncaught ReferenceError are the most common application errors. They mean your code tried to do something with a value that wasn't what it expected — calling a method on undefined, or referencing a variable that doesn't exist in scope. The stack trace tells you exactly where. Always include these in bug reports.

Unhandled Promise Rejection means an async operation failed and nothing caught the error. In modern web apps, this often means a failed API call that your app silently swallowed. The rejection reason — sometimes a full server error object — appears in the console log. This is frequently the root cause of UI elements that fail to populate data without showing an error state.

Content Security Policy (CSP) violations appear as Refused to load script/style/image from 'https://...'. These are easy to miss because they don't look like traditional errors, but they mean something on your page is being blocked from loading. In most apps, a CSP violation means either your policy is overly restrictive (a misconfiguration bug) or something unauthorized is trying to inject content (a security issue). Both deserve a bug report.

The error types that usually don't matter

Deprecation warnings are printed by browser APIs or third-party libraries when you use a feature that's scheduled to be removed. They almost never affect current functionality. File them as technical debt if your team tracks that, but don't mix them into active bug reports.

Chrome extension errors appear with source URLs beginning chrome-extension:// or moz-extension://. These come from the user's browser extensions — ad blockers, password managers, developer tools. They are not your application's errors. If you see them, right-click the console and hide messages from that source before taking your screenshot.

Third-party script errors from analytics, chat widgets, or payment libraries often appear in the console. Unless the error appears immediately before or during the bug you're reporting, they're background noise. Check the source URL — if it's not your application's domain, treat it as low-priority unless it's clearly the cause of the issue.

CORS errors: the special case

CORS (Cross-Origin Resource Sharing) errors look alarming — Access to fetch at 'https://api.example.com' from origin 'https://app.example.com' has been blocked — but they're almost always a configuration issue rather than an application code bug.

Before filing a CORS error as a bug, check:

Does this error appear in production, or only on localhost/staging?
Is the API you're calling on a different subdomain from your app?
Did anything change in the backend deployment recently?

If the error only appears locally, the fix is adding the appropriate CORS headers to your local/staging server config — not an application code change. If it appears in production, file it immediately: users are seeing broken functionality.

Reading a stack trace: the minimum you need

A stack trace is a list of function calls, from the most recent (top) to the one that started the chain (bottom). For a bug report, you don't need the whole thing. You need:

Line 1: the error message — TypeError: Cannot read properties of undefined (reading 'map')
Line 2: the topmost frame in your application code — the file and line number. Ignore frames from node_modules.
The URL you were on when the error appeared

Three pieces of information. The developer can reconstruct the rest from there.

Putting it in the bug report

Don't screenshot the console — copy it as text. Right-click the error in the console and select Copy message or Save as... to export the full log. Paste it as a code block in the ticket. A text error is searchable, diffable, and copy-pasteable into a local environment; a screenshot of an error is none of those things.

The format: one paragraph explaining what you were doing when the error appeared, followed by the full error text in a code block, followed by your screenshot showing the visible UI state. That's everything a developer needs to start debugging without asking you a single question.