* 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
* The `processMutations` function needed to be bound to the `mutationBuffer` object, as otherwise `this` referred to the `MutationObserver` object itself
* Enable external pausing of mutation buffer emissions
- no automatic pausing based on e.g. pageVisibility yet, assuming such a thing is desirable
https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
- user code has to call new API method `freezePage` e.g. when page is hidden or after a timeout
- automatically unpauses when the next user initiated event occurs
(am assuming everything that isn't a mutation event counts as 'user initiated'
either way think this is the correct thing to do until I see a counterexample
of an event that shouldn't cause the mutations to be unbufferred)
* Avoid a build up of duplicate `adds` by delaying pushing to adds until emission time
* Need to export freezePage in order to use it from rrweb.min.js
* Add a test to check if mutations can be turned off with the `freezePage` method
* I noticed out of order ids (in terms of a DOM walk) in a FullSnapshot. A DOM mutation was executed against the mirror asynchronously before it could be fully processed. This would lead to a situation in replay where a mutation is executed against a DOM tree that already has the mutation applied. This changeset fixes that by freezing any mutations until the snapshot is completed.
* Remove attribute modifications from a mutation event that were incorrect in that they were repeating the attributes of those nodes present in the 'adds' array of the same mutation
* I've manually verified that this empty text node is actually removed when the dropdown is opened:
document.getElementById('select2-results-1').childNodes
NodeList(2) [li.select2-results-dept-0.select2-result.select2-result-selectable.select2-highlighted, li.select2-results-dept-0.select2-result.select2-result-selectable]
and also that it is not reinstated after the second `await page.click('.select2-container');`
* Rearrange when removal happens in order to satisfy tests. I'm also reverting a recent test change (2600fe7) so that tests pass after this rearrangement; I believe that test change to still be the correct way of doing it, but maybe it is not strictly important that there are extra mutations on attributes of just added nodes
* As mutations are now paused during FullSnapshots, we shouldn't be counting this as a 'user emission'. We automatically emit mutations after unpause anyway ('emit anything queued up now')
* Ensure that we clear arrays before emitting, as the mutation could have the side effect of triggering a FullSnapshot (checkoutEveryNth), which would otherwise re-trigger emission of same mutation (through the new pause/fullsnapshot/mutationemit/unpause process)
* Don't let the programattic pausing during TakeFullSnapshot accidentally unpause a manual call to the API method `freezePage`
* Rename paused -> frozen for consistency and change to use getter/setter access methods
* 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
* part of #80, support mask input options
* close#188 enhance sampling options
Use a more general sampling strategy interface to describe the
configuration of sampling events collection.
Implemented mousmove, mouse interaction, scroll and input sampling
strategy.
* Move mutation processing into it's own object.
This should stand on it's own as a refactor, but is intended as a basis
for exposing the new MutationBuffer object to further outside control e.g.
to 'mute' or batch up mutation emission when the page becomes inactive
from a https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
point of view
* The `processMutations` function needed to be bound to the `mutationBuffer` object, as otherwise `this` referred to the `MutationObserver` object itself
* Neglected to add this output of `npm run typings`
* Get around the binding problem by using Arrow function expressions
* Prettier formatting
There are some long-term issues in rrweb's mutation observer.
A scenario cause problem:
A list of DOM node: n1, n2, n3, n4, n5
Steps of modifying the nodes:
1. remove n1, n2, n3, n4 sequentially
2. append n4, n3, n2, n1 after n5 sequentially
Then we got the added node data like this:
(id: n4, prev: null, next: n3 )
(id: n3, prev: n4, next: n2 )
(id: n2, prev: n3, next: n1 )
(id: n1, prev: n2, next: null)
The problem comes when we try to replay the first add node datum.
Since its prev node is null, we rely on its next sibling n3. But
n3 was not present at this moment, and in previous code, we fallback
to append n4 to the last of its parent node.
The solution is to defer the append of elements that missing
siblings. But it is also hard to tell which node is the first one
that needs to be appended.
Take a step back and rethink the design of the mutation observer,
we've found there are two implementations make things complicated.
1. We set the id to -1 when we seeing some nodes are not serialized yet.
2. We record both previous sibling and next sibling to determine the
position of the node.
But we can do better!
First, we can put nodes with un-serialized siblings
to a queue, and try to add it again later. Then we can just record the next
sibling as 'the single truth' so we can be sure which node is the last
one of its parent.
This patch has implemented the new observer strategy. Data recorded with
the new observer should no longer have any node with id -1. But for
compatibility consideration, we still keep some replayer code that helps
solve legacy data.
* hack together stylesheet observer
* Add test coverage for insertRule/deleteRule on stylesheets
* Add new observers
* update patch based on changes to master
* Functioning event recording
* Remove print statements
* Fix ID usage and mark add vs remove
* Correct type
Co-authored-by: Jon Perl <perl.jonathan@gmail.com>
Originally we use Array.from to transform iterator into array.
But we found some framework may overwrite the Array.from with a
pollyfill which was not implement correctly.
* added our package
* reverted back to old rrweb snapshot
* Array.from does not capture all elements added in the set, we have to manually iterate through the iterator
* package lock
This is an important patch contains some crtical bug fixes for
the DOM mutation observer.
Previously the observer did not handle complex DOM movement very
well. So in this patch we optimized this by distinguishing moved
node better and added a resolving queue to avoid the error caused
by ordering.
Increase the throttle value of collecting mouse move and add a
transition time to the replayer's mouse. This may decrease the
size of mouse move data and make the replay movement more smooth.
Another change is to move and hover when click event is replayed.
This is to improve the replay of some programmatic click, such as
E2E tests.
If an element was blocked, its child nodes should also be blocked.
The interactions and mutations on the element and its child nodes
also need to be blocked.
This change include two critical fix for both recorder and replayer.
In the recorder, previously we filter text and attribute mutations by check its target id,
but this was a wrong approach because removed node also has id at the callback moment.
We corrected this by checking whether the mirror map still has the target id in its keys.
In the replayer side, the issue was we got exceptions when calling insertBefore which says
the ref node was not the child node of the caller node. This will happen when the previous
or next sibling has been removed in the same callback but the previousId or nextId was
recorded.
After apply remove node mutations before add node mutations, we can make sure the removed
siblings will not exist in the mirror map when apply add node mutations. When we get node
from mirror map with an removed id, we will get null and pass it to insertBefore which
is valid.
As a side note, this apply order is safe because we ensured all the remove node mutations
do not include removing newly added nodes in the same callback.
