@webkit-masked-url: (//hidden/)

[Shramkoweb]

Hello. I began to see such errors in my project:

//hidden/ in y@webkit-masked-url: at line 2:2930760
//hidden/ in fromAny@webkit-masked-url: at line 2:2931890
//hidden/ in _handleResponsePromise@webkit-masked-url: at line 2:1144366
//hidden/ in _handleDispatchResponse@webkit-masked-url: at line 2:1144141
//hidden/ in _handleMessage@webkit-masked-url: at line 2:1143837
//hidden/ in @webkit-masked-url: at line 2:1143638
//hidden/ in emit@webkit-masked-url: at line 2339:17
//hidden/ in @webkit-masked-url: at line 2138:26

I can't understand what it is, why the sentry throws them. It looks like a code problem in Safari itself

[lforst]

Hi, this doesn't look familiar to me and I have to say this doesn't look like an error caused by the SDK itself. Would you mind raising an issue in the webkit repo asking what the reason for stack traces like that might be? Would be kinda interesting for us too!

[Shramkoweb]

@lforst https://bugs.webkit.org/show_bug.cgi?id=246010

[lforst]

I see the webkit folks provided some context. I guess if these errors come from a safari extension you can safely ignore them: https://docs.sentry.io/platforms/javascript/configuration/filtering/#decluttering-sentry

[Shramkoweb]

I see the webkit folks provided some context. I guess if these errors come from a safari extension you can safely ignore them: https://docs.sentry.io/platforms/javascript/configuration/filtering/#decluttering-sentry

yeah. Thank you 👍

[MrJoy]

Is there a reason that events with stack traces like this are not filtered out by the "Filter out errors known to be caused by browser extensions" setting?

[MrJoy]

Also: The client-side filtering options all seem to match against the error message, not the stack trace. Am I missing something there?

[lforst]

Is there a reason that events with stack traces like this are not filtered out by the "Filter out errors known to be caused by browser extensions" setting?

I think we could add it. Right now I am unsure if we will potentially overshoot our target if we ignore these errors. Maybe there are errors with these kinds of stack traces we wanna keep. I am leaning towards just ignoring them though 🤔

Also: The client-side filtering options all seem to match against the error message, not the stack trace. Am I missing something there?

Correct. Some part of it is historical reasons - another part of it is because stack traces can look very different on individual browsers. If you wanna ignore events based on the stack trace you can use beforeSend. There you have access to the parsed stack trace.

[MrJoy]

I'd definitely prefer if Sentry handled this as part of the big easy hard-to-get-wrong toggle, but I understand the caution. My intuition says that it shouldn't be possible for this sort of stack message to show up in anything except a browser plugin caused exception but browser security contexts are a nightmare of complexity.

Is there documentation on the exact type structure for the event parameter to beforeSend, including what fields can be null? I considered going that route but am hesitant to proceed since I don't have a clear way to verify that my changes won't break and cause an error within the error handling due to corner-cases I didn't anticipate.

[lforst]

I'd definitely prefer if Sentry handled this as part of the big easy hard-to-get-wrong toggle, but I understand the caution.

We will probably add this: #7993

Is there documentation on the exact type structure for the event parameter to beforeSend, including what fields can be null?

Generally, you can refer to the TypeScript type definitions.

[mydea]

Hi @Shramkoweb ,

we are currently looking into filtering these out server-side. Could you provide us with a full error & stack trace for an example of this, or even better, provide a link to a sentry issue? that would greatly help us to make sure our fix works.

[lforst]

Hi, @Shramkoweb I sent you an email. @mydea is on vacation

[Shramkoweb]

Hi, @Shramkoweb I sent you an email. @mydea is on vacation

done. Feel free to contact me if you need more info.

[mydea]

Hey, I believe (correct me if I'm wrong @TBS1996) these issues should now be filtered server side.

[Shramkoweb]

Hey, I believe (correct me if I'm wrong @TBS1996) these issues should now be filtered server side.

From what version?

[mydea]

Are you using self-hosted or SaaS Sentry? In SaaS, it should already be working I think. For self-hosted, not 100% sure if it is out yet, but at least with the next release it should be included.

[yutotb]

Hi!!!!
How is everyone setting up ignore?
I want to know how to write it specifically.

[AJenbo]

This might be helpful, though I haven't tested it yet:

Sentry.init({
  dsn: 'your-dsn',
  beforeSend(event) {
    // Check if the event contains stack traces
    if (event.exception) {
      // Look through each stack trace frame
      for (let frame of event.exception.values[0].stacktrace.frames) {
        // Check if the frame's filename indicates a browser extension
        if (frame.filename && frame.filename.startsWith('webkit-masked-url')) {
          return null; // Discard the event
        }
      }
    }

    // If the event doesn't seem related to a browser extension, keep it
    return event;
  }
});

[stovmascript]

Was anybody successful with doing it in ignoreErrors? I'd rather not implement beforeSend if possible.

[lforst]

ignoreErrorsis only for error messages. You could try denyUrls.

[stovmascript]

Nice, will try.

@lforst I also noticed that this specific issue should be filtered in Sentry by default since v23.6.0? We're running v25.1.0 (self-hosted) and are still seeing issues with 'webkit-masked-url'.