Error events from nested iFrame do not contain source map debugID reference.

[rodolfoBee]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

9.2.0

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

There is a sandbox app where the issue happens and more details on how it is configured are available in this internal ticket
See the internal comment from 28/02 with a summary of information.

Steps to Reproduce

1. Add the Browser SDK to an app with nested iFrames.
2. Use webpack plugin to upload source maps to Sentry

sentryWebpackPlugin({
authToken: SENTRY_AUTH_TOKEN,
org: <redacted>,
project: 'editor',
telemetry: false,
});

3. Throw an error in the iFrame

Expected Result

The event sent by the SDK has source maps debugIDs attached to them.

Actual Result

The event does not have the DebugID reference under debug_meta.

Because webpack rename the uploaded files, the fallback of matching abs_path to the uploaded source maps also also fails. Source maps are hosted internally with no access from outside, thus source map fetching also fails.

I can confirm that the minified file has the correct debugID, which is found in the uploaded files to Sentry:
Minified file contains:

p._sentryDebugIds[u]="9ef9d18e-3246-411d-9336-512a031cf002"
...
SENTRY_RELEASE={id:"a5fffa11f6d7735ecd9ddea4d9fd56d64f2b85e1"};

Screenshot from project settings with the uploaded file:

[lforst]

Seems like the events in question do not have debug IDs attached to them. To me this means that when the error happened, either the debug ID snippets haven't been executed yet (very unlikely / impossible), or the debug IDs do not live in the current global context from where the error was captured. This would make sense if the errors originate from an iframe since the parent window and the iframe don't share a global object (as far as I know). I think this would happen if you did something like this for example: https://stackoverflow.com/a/14041297/21967320 and capturing the exception in the onerror handler.

A way to get around the above would be to also initialize an SDK in the iframe. It could point to a different project, or the same one. Doesn't really matter as long as the right project has the right artifacts uploaded.

You can also use the legacy source map upload that does not depend on debug IDs but artifact paths: https://docs.sentry.io/platforms/javascript/sourcemaps/troubleshooting_js/legacy-uploading-methods/ It would make use of the uploadLegacySourcemaps option: https://www.npmjs.com/package/@sentry/webpack-plugin#releaseuploadlegacysourcemaps

[mbarzeev]

Thanks!

A way to get around the above would be to also initialize an SDK in the iframe. It could point to a different project, or the same one. Doesn't really matter as long as the right project has the right artifacts uploaded.

Does this have the potential of creating duplicate events in Sentry, where some are with source maps and others are without?

[lforst]

Does this have the potential of creating duplicate events in Sentry, where some are with source maps and others are without?

It depends on your setup. If you are sending over the errors to the parent window, then yes, the errors will be captured twice. You could somehow in a generic location set a property on the errors before they're being propagated upwards to the parent, and in the SDK in the parent window use beforeSend or an event processor to drop error events for errors containing that property.

[mbarzeev]

@lforst Given that Sentry is initialized both on the top window and the child iFrame, do you think that if we prevent the error from propagating up it would be sufficient to prevent duplications? And if we prevent it, will Sentry still capture it?
Do we need to do something of this sort on the iFrame:

window.addEventListener("error", function (event) {
    Sentry.captureException(event.error || event.message);
    event.stopPropagation();
}, true);

[mbarzeev]

Hi @lforst,
We've added an error (just for your user) that should happen when you attempt to select any element on the Editor's canvas (a console log which references an undeclared variable).
I hope that this will help you investigate further.
Thanks

[chargome]

We've added an error (just for your user) that should happen when you attempt to select any element on the Editor's canvas (a console log which references an undeclared variable).

Hey @mbarzeev just tried this but could spot the error in your issue stream, could you specify the error name? Also looked for my specific url in tags but couldn't find it.

[mbarzeev]

Hi @chargome,
The reason you don't see it is since we enabled it for what we call "Flex site" or "Editor2.0".
I've created one on you account (called "flexsite"), and there you should be able to reproduce (tried it myself and it did).
The error you're looking for is

Uncaught ReferenceError: nonExistentVariable is not defined

Thanks.

[chargome]

Hey @mbarzeev thanks for clarifying, I was now able to produce an error and inspect it in your issue feed. Could confirm that the SDK is initialised on your iframe.

It looks like the issue is actually sourcemapped with debugId references?

[mbarzeev]

You are right, it does appear to have the source map (with the misalignment in lines, but that's another story). I wonder why we didn't get that earlier... either we missed something, or the nature of the error was different 🤔
In any case, is it possible to reach this result without also initiating Sentry on the iFrame? What is the bug which keeps clearing out the debug-id from the event for nested iFrame?

[lforst]

In any case, is it possible to reach this result without also initiating Sentry on the iFrame?

If you are using debug IDs the SDK must be initialized in the iframe. If you're ready to go through the pain of matching sourcemaps to stackframes via file-path you can also use the legacy uploading method.

What is the bug which keeps clearing out the debug-id from the event for nested iFrame?

I doubt there is a bug. To me it seems like the SDK was previously not initialized in the iframe. Note that when you are passing errors from iframe to parent, sourcemapping will not work - so if you are still doing that, you may get unmapped events.

[mydea]

Why was this issue closed?

This issue hasn't been touched recently and no longer seems relevant.
Hence, we're closing it to maintain a clean and transparent backlog.

Please feel free to leave a comment if you think this issue should be reopened.