Filter Browser Extension Errors from Client Error Reports

[bobular]

[This is a largely Claude-generated PR.]

Problem

We've been receiving client error reports for errors that don't originate from our application code. For example, errors related to "Zotero" (a browser extension for managing citations) have been appearing in our error logs, even though Zotero is not part of our codebase (frontend or backend).

These errors come from:

• Browser extensions (Chrome, Firefox, Safari extensions like Zotero, ad blockers, password managers, etc.)
• Third-party scripts loaded from external domains
• Cross-origin resources that fail or throw errors

This noise makes it harder to identify and fix genuine application errors.

Solution

Added filtering logic to UnhandledErrorStoreModule.ts that detects and excludes third-party errors before they're reported to the server.

Changes Made

File: packages/libs/wdk-client/src/StoreModules/UnhandledErrorStoreModule.ts

1. New isThirdPartyError() function - Detects browser extension and third-party errors by checking:

   • Extension URL protocols (chrome-extension://, moz-extension://, safari-extension://)
   • Cross-origin script filenames (errors from domains other than ours)
   • Stack traces containing extension URLs
   • Extension-specific patterns in error messages

2. Updated error event listeners - Both the promise rejection handler and global error handler now filter out third-party errors before creating error reports

What Gets Filtered

✅ Browser extensions (Zotero, LastPass, Grammarly, ad blockers, etc.)
✅ Third-party scripts from external domains/CDNs
✅ Cross-origin errors that don't come from our application

What Still Gets Reported

✅ All genuine application errors from our own codebase
✅ Errors from our same-origin scripts
✅ All previously-filtered errors (ResizeObserver, WebGL, etc.)

Testing

• TypeScript compilation passes
• Build completes successfully
• No breaking changes to error reporting infrastructure
• Existing error boundary and reporting mechanisms unchanged

Impact

After deployment, we should see a significant reduction in false-positive error reports. This will improve:

• Signal-to-noise ratio in error logs
• Ability to identify real application issues
• Server load from unnecessary error submissions

Future Enhancements

If we identify specific extension error patterns in production logs, we can easily add them to the filtering logic.

[aurreco-uga]

awesome!