Replay causes error `Blocked a frame with origin <hostname> from accessing a frame with origin "https://js.stripe.com"` in Safari when Stripe payment form is on the page

[jakst]

Is there an existing issue for this?

• [x] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• [x] I have reviewed the documentation https://docs.sentry.io/
• [x] 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

8.22.0

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  replaysSessionSampleRate: 1,
  integrations: [
    Sentry.replayIntegration({
      block: ["iframe"],
    }),
  ],
})

Steps to Reproduce

A minimal reproduction repro with a deployed example is available at https://github.com/jakst/sentry-replay-stripe. Basically running the Sentry Replay integration when a Stripe form is rendered causes this error Blocked a frame with origin "https://sentry-replay-stripe.vercel.app" from accessing a frame with origin "https://js.stripe.com".

I was following along in https://github.com/getsentry/sentry-javascript/issues/6560 and though the issue was resolved, but even though I have confirmed the claimed fix is present in our version of the SDK, we still get this error with the stripe form together with Sentry Replay.

Expected Result

I would expect that setting block: ["iframe"] allows us to render the Stripe payments form without getting any errors.

Actual Result

This error is written in the console on Safari

Blocked a frame with origin "https://sentry-replay-stripe.vercel.app" from accessing a frame with origin "https://js.stripe.com". Protocols, domains, and ports must match.

[billyvg]

Ah, it's likely that we don't check the block attribute when an iframe gets added to the DOM after the snapshot.

[jakst]

Ah, it's likely that we don't check the block attribute when an iframe gets added to the DOM after the snapshot.

Yeah that sounds like it could be it!

[andreiborza]

@billyvg I've assigned this to you. Let me know if there's something we can help with.

[jakst]

@andreiborza @billyvg https://github.com/getsentry/rrweb/pull/212 was just released in Sentry. I tried upgrading to v8.28.0 in my reproduction repo, but the issue is still there for me. I have confirmed that the changes from https://github.com/getsentry/rrweb/pull/212 are included in the release.

Would you consider reopening this issue? Here's the deployed app with the issue https://sentry-replay-stripe.vercel.app. You can find the repo in the original description.

[billyvg]

@jakst thanks, looks like we are attempting to attach a load event listener to the iframe even if it is blocked (I believe this is semi-intentional since we want the dimensions of the iframe after it loads because the dimensions are used for the iframe placeholder).

[jakst]

Should I interpret that as "working as intended"? Or will you investigate if there are ways around it? If the browser blocks the listener from attaching to the iframe anyway, it doesn't sound like it needs to run in this case

[billyvg]

No, no conclusion yet, I've just identified the code in question (and a possible side-effect). We'll have to look into this a bit more and see if conditionally attaching event listener will cause anything unintended

[metalmarker]

I'm experiencing the same issue, but without having Replay enabled. The only integration I have on init is reactRouterV6BrowserTracingIntegration.

I'm on sentry/react@8.30.0.

[andreiborza]

@metalmarker thanks for chiming in. Could you provide a minimal reproduction repo or stackblitz