Safari Web Extension Error Stack Traces in Sentry Show webkit-masked-url://hidden/ — Any Way to Restore Real Script Paths?

I’m a developer working on a Safari Web Extension that’s distributed via the App Store and also tested locally through Xcode. I’m running into an issue that’s affecting my ability to debug errors reported to my Sentry error logging instance from production.

The Problem

When an error is thrown in one of my extension scripts (e.g., background.js, popup.js, or content.js), the error is sent to Sentry but the captured JavaScript error stack trace replaces the file paths with the webkit-masked-url://hidden placeholder like this:

ReferenceError: Cannot access uninitialized variable.
  at ? (webkit-masked-url://hidden/:14677:28)
  at ? (webkit-masked-url://hidden/:16307:3)

This happens consistently across both App Store builds and local Xcode runs. It prevents me from seeing which script the error came from or resolving the actual source code lines using uploaded source maps in Sentry.

My Setup

  • Safari Version: 18.5 (Stable on macOS)
  • Distribution: App Store and local Xcode development
  • Extension Type: Safari Web Extension
  • Error Reporting: Sentry (@sentry/browser SDK)
  • Bundler: Webpack with inline-source-map

What I’ve Confirmed

  • I can see the actual source files in Safari’s Web Inspector under the Sources tab when the extension is running.
  • My source maps are uploaded to Sentry correctly and are associated with the matching release.
  • Errors from Safari are being captured by Sentry, but the file URLs are masked, so stack traces cannot be resolved against my original source.

My Question

Is this behavior (masking file URLs in stack traces with webkit-masked-url://hidden/) intentional for Safari Web Extensions?

If so, is there any supported method or workaround to allow exception stack traces to reveal the original script path (e.g., popup.js, background.js) so tools like Sentry or even console logs can point to real locations? I fully understand the privacy/security rationale behind the masking, but as the extension developer, this is making it extremely difficult to debug runtime issues in production.

I’d really appreciate any insight into:

  • Whether this masking is expected and permanent behavior
  • If there are any entitlements, debug settings, or Info.plist keys that can alter this behavior for development or for trusted/own extensions
  • If Apple recommends a different way to log extension errors that includes script name or source references

Thanks in advance for your help! I’m happy to share more technical details or try out suggestions.

Safari Web Extension Error Stack Traces in Sentry Show webkit-masked-url://hidden/ — Any Way to Restore Real Script Paths?
 
 
Q