rrweb sends message to cross-origin iframe to force snapshot #1465
Conversation
🦋 Changeset detectedLatest commit: 01d107f The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
colingm
force-pushed
the
cgm/cross-origin-snapshot
branch
3 times, most recently
from
950f836 to
fa0208e
Compare
colingm
force-pushed
the
cgm/cross-origin-snapshot
branch
from
37ac6f7 to
debf898
Compare
|
Is there a possibility that this will duplicate the regular way to take an iframe snapshot (when the contentDocument is accessible)? |
|
@eoghanmurray I am not quite sure if this can be triggered before the inner frame ends up being ready, will need to test that specifically. In practice we don't run into that problem since we don't try to initialize rrweb until the document is ready ourselves so it is worth double checking. In general the idea that the top frame taking a snapshot (either due to the checkoutN options or manually) means you lose the inner frame entirely was definitely the major concern but it is a good idea to make sure it doesn't mess with delayed initializations for the inner frames. |
| @@ -216,6 +216,7 @@ export type CrossOriginIframeMessageEventContent<T = eventWithTime> = { | |||
| // The origin of the iframe which originally emits this message. It is used to check the integrity of message and to filter out the rrweb messages which are forwarded by some sites. | |||
| origin: string; | |||
| isCheckout?: boolean; | |||
| snapshot?: boolean; | |||
There was a problem hiding this comment.
This note is a reminder that we need to add a test
|
Adding a note here as doing some testing with timing of things and have found some oddities where it might not be behaving as expected due to the ordering of definition for |
|
fwiw we also have this use case! |
There was a problem hiding this comment.
Looks really good @colingm! Curious what (edge) cases you've come across, and it would indeed be nice to have a test to make sure this stays working.
Easy-ish way to test this, is load rrweb (but don't record) in a page with cross origin iframe, then after everything is loaded: start recording. Iframe won't be recorded in the way its currently setup, but will with your fix.
|
@Juice10 yeah sorry I have kind of let this languish unfortunately. So we actually found with the original version we had a weird race condition where it wasn't doing what we thought most of the time. We changed how we passed in the function (a setter now being called later) and that seemed to address the odd behavior we saw. Now just to write the tests 😅 |
We often manually take snapshots in cross origin frame situations and were running into problems with no longer having the content of cross origin frames. We noticed that if we sent along a message to tell the cross origin frame to take a new snapshot whenever the parent frame took one then it resolved this issue.