record same origin <iframes> (and maybe other frames?)

[eoghanmurray]

I wish to record a website which has an embedded iframe, for which the
document.getElementsByTagName('iframe')[0].contentDocument.body
is accessible from the containing page (where the recorder is active).

I'm going to attempt a patch to get this included in the recording, but let me know if there are any thoughts, or situations where this would not be desirable?

[no-1ne]

Iframe recording seems to be one of the top requested feature.

There seem to be some prior work done on this by lib author #68

[no-1ne]

If you are planning to take a stab at it, kindly consider shadow-dom issue as well, details and possible solution in the comment, #38 (comment)

[Yuyz0112]

I have a local branch that works on some simple iframe scenario.

The problem is there are two different approaches:

1. Record iframe as a nested DOM
2. Execute the record function in the iframe document and merge events

Each of the approaches has some problem to solve.

[eoghanmurray]

Ok, I think I underestimated the problem as I forgot about recording events inside the iframe in the nested DOM approach.

Could we do #2, but have the containing document automatically kick off the recording (with the same config, except for the emission handler), and have the nested document emit changes up to the containing document, which then re-emits it normally?

e.g. for message exchange: https://gist.github.com/pbojinov/8965299

[eoghanmurray]

This pull request: #294
is probably related;
it was intended for when the rrweb code was loaded within a 'sandboxed' iframe, to 'bust out' of the iframe into the real top-level page.
This type of code loading is sometimes the only way of adding 3rd party HTML/Javascript in hosted content management systems.

If we were doing that, then it would make sense to have a master/singleton instance of rrweb at the highest window, which then launches all the nested instances which report back to it.

[Yuyz0112]

#481