Session Replay on Mobile Javascript Appears Longer Than the User's Screen

[thinkocapo]

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

7.118.0

Framework Version

No response

Link to Sentry event

https://global-e-yb.sentry.io/replays/1c365b2d8e184d48b137d470460b10ce/?t_main=errors

Reproduction Example/SDK Setup

Setup

It's an inframe injected into a merchant site, so the scroll is on the store side and not as part of the iframe. User It's browser Javascript running in Mobile Browsers like Mobile Chrome and Mobile Safari.

Problem

All the text and stuff in the session replay is way to small for reading. Pinch-zoom'ing on the browser doesn't help. It's also showing way too much of the app, which the user does not see all at once.

It's a Viewport problem.

If the replay is 1minute long, then in the first second of the replay you already see the entire app as if the user already scrolled vertically to the very bottom of it.

You see screens all at once: A B C D E

But if the user is slowly scrolling vertically then initially you should only see in the replay: A then B then C

Attempted Solutions

"it's possible we can make a workaround if they can pass the parent container's height (or grab height from inside the iframe) and pass into the replay integration."

“We have 2 options, move sdk to outside the iframe, but then will it still capture iframe, and we capture corporatepartner1+corporatepartner2's product search pages, we really don’t want or need that (legal reasons). or keep it inside the iframe but give us the ability for us to update you on where the current scroll is on the page”

"another possibility is to have rrweb not record everything and make an exception for their iframe (though I totally understand their hesitation to do this)"

Attach listeners in the parent document for window resize and scroll (you’ll probably want to debounce these events too). This data will need to flow to inside of the iframe where you will send this data to Sentry. Note that the window dimension event needs to happen after the native event that sets the resolution, otherwise the parent’s dimensions will get overwritten. You’ll then need to use some private API’s to send the event:

// Sentry.getClient().getIntegrationByName('Replay')
const replay = Sentry.getReplay();
replay._replay.eventBuffer.addEvent({
  type: 4,
  timestamp: new Date().getTime(),
  data: {
    href: ‘’,
    width: <number (pixels)>,
    height: <number (pixels>,
  }
});
replay.flush();

Similarly with the scroll:

replay._replay.eventBuffer.addEvent({
  type: 3,
  timestamp: new Date().getTime(),
  data: {
    id: -1,
    source: 3,
    x: <x position>,
    y: <y position>,
  },
});

Q. The height of the iframe is fixed, what should we pass in the resize event? A. It should be height of the parent document window that contains the iframe but yeah it can just be initial size if it doesn’t change

Q. What should be passed at width height if the iframe height is fixed? A. For width/height, need to get the e.g. window height/width

Result - We saw the resize happening ~:49 seconds in but it quickly switches back -- it's something we can potentially get working. May require adding bundle size to the rrweb library.

Steps to Reproduce

It's an iframe injected into a merchant site, so the scroll is on the store side and not as part of the iframe. User It's browser Javascript running in Mobile Browsers like Mobile Chrome and Mobile Safari.

Expected Result

A session replay video that's viewable and readable.

Actual Result

A session replay video that's not so zoomed out, and probably not showing all of the screens from vertical scroll at once. Hard to explain without a screenshot of customer's session replay.

[Lms24]

It's an iframe injected into a merchant site, so the scroll is on the store side and not as part of the iframe.

To confirm, the users want to use session replay only for a widget that's injected into a host page? This is not a supported use case for session replay. It came up multiple times already in the past but it's a technical limitation of rrweb that we cannot only record a part of a page. I added this issue to the Replay team's project for them to confirm (or correct) what I wrote.

Looking at the replay, it does look like more than the viewport is recorded but I'd rather only look into this once we have confirmation of the intended use case of replay in this case.

[gil-gross-glbe]

Our checkout operates inside a fixed-height iframe embedded on merchant sites. The current session replay implementation results in an unusably small/zoomed-out view on mobile devices, showing the entire vertical content at once instead of following the user's scroll through the parent window. We've attempted several workarounds, including:

Passing parent container height/scroll info to the iframe Using private APIs to send custom resize/scroll events Adjusting replay integration settings

However, these attempts haven't fully resolved the issue. This functionality is critical for us to effectively debug and improve our checkout experience across various merchant sites. We understand this may not be a currently supported use case, but it's crucial for our business. We're open to any potential solutions or workarounds that could make session replay viable for our iframe-based checkout system.

[scefali]

@billyvg Is there any way we can get replay working with an iFrame? I am working with a client that also wants to do this. I saw @Lms24 said that rrweb doesn't support recording in an iFrame but based on an issue on GitHub I think they do now? Not an expert here so I could use some guidance.

[Lms24]

@scefali happy to let @billyvg chime in with thoughts but from what I know, Replay will only work properly if instantiated on the host and the iframe being a 1st party (same domain) iframe.

[ldorigo]

(I'm @scefali 's client) I'm a bit confused because sentry does work inside the iframe when the iframe is rendered in a fixed sized container (e.g. when a customer's directly includes our iframe within a

in their webpage); in that case sentry is running inside the iframe and on a different domain from the parent window.

But it does not work when we render it through javascript injection, the code for that looks something like:

function createChatIframe() {
    lwChatIframe.id = lwChatiFrameId
    lwChatIframe.src = window.learnWiseSetup.chatSrc
    lwChatIframe.style.display = 'none'
    lwChatIframe.allow = 'microphone'
    document.body.appendChild(lwChatIframe)
}

function closeChatIframe() {
    lwChatIframe.style.display = 'none'
}

function openChatIframe() {
    lwChatIframe.style.display = 'block'
}

I wonder if it's due to the fact that the iframe is initially set as display: none and sentry doesn't register when it gets opened? (We provide a chatbot that users open by clicking on a small floating icon).

Replays look like this: https://github.com/user-attachments/assets/35c7376c-4f53-4c79-b84b-9e969566cf56

[s1gr1d]

Am I understanding this correctly?

• You are providing a chat iFrame which customers can add to their page
• When customers add this chat iFrame to their page, it's not a same-origin iFrame (the origin of the iFrame is your URL)
• If this cross-origin iFrame is added to a customers page, Sentry works in the iFrame?
• In general, you just want Sentry to be enabled in your chat iFrame?

And it could be because of the display CSS setting. Are you able to try it without this?

[billyvg]

@ldorigo In the case where it's not working, is Sentry running inside the iframe or on the host page? Is it possible for you to add the replay integration only when you change display: block?

[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.