* 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
* 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
Loop the append queue has been proved to be very inefficient, and
some times lead to N^2 time complexity.
Especially when some abnormal data could not be appended into the
real DOM, will make a dead loop.
Previously we use a 5000ms time out to handle this, which is not
user-friendly and not explicitly.
In this patch, we transform the queue into a tree data structure,
which reflects the layout of real DOM. With the tree data structure,
we can find whether there are dangling nodes that need to be dropped.
Also, the iteration will be much more efficient.
There is still a 500ms time out to avoid a dead loop, but should not
be called in expected scenarios.
* record canvas mutations
close#60, #261
This patch implements the canvas mutation observer.
It consists of both the record and the replay side changes.
In the record side, we add a `recordCanvas` flag to indicate
whether to record canvas elements and the flag defaults to false.
Different from our other observers, the canvas observer was
disabled by default. Because some applications with heavy canvas
usage may emit a lot of data as canvas changed, especially the
scenarios that use a lot of `drawImage` API.
So the behavior should be audited by users and only record canvas
when the flag was set to true.
In the replay side, we add a `UNSAFE_replayCanvas` flag to indicate
whether to replay canvas mutations.
Similar to the `recordCanvas` flag, `UNSAFE_replayCanvas` defaults
to false. But unlike the record canvas implementation is stable and
safe, the replay canvas implementation is UNSAFE.
It's unsafe because we need to add `allow-scripts` to the replay
sandbox, which may cause some unexpected script execution. Currently,
users should be aware of this implementation detail and enable this
feature carefully.
* update canvas integration test
- What was broken was that it would just play activity from the first page view, but then would stop at the second page view (meta) as actions after that had been discarded
- This restores the functionality given by the comment 'return the events from last meta to the end.' - we never want to discard events that are after the baseline time
- I believe 'session' is the incorrect terminology for this function name, as a session in web analytics usually means a series of page views
