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
Previously we use a regexp to match all the CSS selectors and add
our hover class name to it, which has been proved not solid and
may be very slow in some situation.
Using a production ready css parser can handle this better and also
provide ability's to do more accurate things to the recorded
stylesheets.
* wip: working on rrweb logger
* wip: can record and replay some simple log
* wip: can record and replay log's stack
* wip: try to serialize object
* wip: record and replay console logger
hijack all of the console functions.
add listener to thrown errors
* wip: record and replay console logger
add limit to the max number of log records
* feat: enable rrweb to record and replay log messages in console
this is the implementation of new feature request(issue #234)
here are a few points of description.
1. users need to set recordLog option in rrweb.record's parameter to record log messages. The log recorder is off by default.
2. support recording and replaying all kinds of console functions. But the reliability of them should be tested more
3. the stringify function in stringify.ts needs improvement. e.g. robustness, handler for cyclical structures and better support for more kinds of object
4. we can replay the log messages in a simulated html console like LogRocket by implementing the interface "ReplayLogger" in the future
* improve: the stringify function
1. handle cyclical structures
2. add stringify option to limit the length of result
3. handle function type
* refactor: simplify the type definition of ReplayLogger
* reuse serialized nodes ids
With this patch, each DOM node keeps its id during its existence. This
allows to apply RRWeb events to previous snapshots if needed.
`resetId` has been removed because it loses its meaning: calling it
would not reset the existing nodes ids anymore, only the new ones.
Since we don't reset the id anymore, we may exhaust the available ids
quicker, but Number.MAX_SAFE_INTEGER (2 ** 53 - 1) is pretty large, so I
doubt this'll cause any problem.
* improv TS typing
The `nAsINode` variable was not very elegant. Simplify this by removing
the cast, and make the INode interface compatible with Node.
* update typings
