* Impl record iframe
* iframe observe
* temp: add bundle file to git
* update bundle
* update with pick
* update bundle
* fix fragment map remove
* feat: add an option to determine whether to pause CSS animation when playback is paused (#428)
set pauseAnimation to true by default
* fix: elements would lose some states like scroll position because of "virtual parent" optimization (#427)
* fix: elements would lose some state like scroll position because of "virtual parent" optimization
* refactor: the bugfix code
bug: elements would lose some state like scroll position because of "virtual parent" optimization
* fix: an error occured at applyMutation(remove nodes part)
error message:
Uncaught (in promise) DOMException: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node
* pick fixes
* revert ignore file
* re-impl iframe record
* re-impl iframe replay
* code housekeeping
* move multi layer dimension calculation to replay side
* update test cases
* teardown test server
* upgrade rrweb-snapshot with iframe load timeout
Co-authored-by: Lucky Feng <yun.feng@smartx.com>
Saw this line cause issues in production, causing the following error:
```
RangeError Maximum call stack size exceeded
```
I believe this is caused by javascript engine max argument length - see note from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply#using_apply_and_built-in_functions
> The consequences of applying a function with too many arguments (that is, more than tens of thousands of arguments) varies across engines. (The JavaScriptCore engine has hard-coded argument limit of 65536.
These were removed in 8ed1c999cf in order to smooth over differences in test environments
so have maintained that by converting pixel values to 'Npx' (could also try rounding, but didn't attempt that)
* added src set as a parsed attribute
* added tests
* changed to /a
* added multiple attribute handling
* added better comment
* made snapshot ignore invalid input as if it is invalid input in the original DOM, it should stay invalid in the recreated DOM
* added extra absolute test case
* code style
* addressed comments
* Tweaks to timings to get tests passing on my dev laptop - hopefully this makes tests more deterministic
* Okay understand what's going on now that the test has run in the travis environment
Broken CSS inside a page will throw an error on our behalf. This should
be ignored because we are not in control of the CSS on the page we are
recording.
I noticed 8 or 10 of these events being generated in a multi-tab browsing session on Chrome 87.0 on Win10. I'm speculating they were generated as a side effect of changing tabs but I can't recreate
