* 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.
* introduce pako and add general packer interface
* add tests for packer
* use function API instead of class API for better tree shaking support
* refcatoring the rollup bundle config
* 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>
This is the record side impl of custom event, according to the
issue, we may also add first-class support for the custom event
tag like display color labels in the replayer-ui.
1. add a liveMode flag to config, when liveMode is set, the timer
will keep running even though all the actions casted
2. add a public method addEvent, which will cast newly added event
in sync
3. move mouse in sync mode with the latest position info
Skip inactive time is an important and useful feature. We consider
user interaction events as active, and check next user interaction
event after apply incremental snapshot.
If next user interaction event has a time gap larger than the
threshold, we will set a dynamic speed value which will skip the
inactive time interval in about 5 seconds.
This patch include a breaking change to the recorder's event data.
We used to consider mirror.getId will always return the id of the
target node because we keep serialize every node. But if we call
mirror.getId before serialization then bug happened. This could
happen when we get nextId of newly added nodes if its next sibling
was also newly added.
So we have to return -1 as the id of node which was not serialized
and when we building added nodes in the replayer we should handle
this.
For example, nodes el1, el2 were added together and el1's nextId
will be -1 since el2 was not serialized at that moment. Now we
call el1 as a 'missing next node' and not append it into the DOM
tree after building, instead we store it in a missingNextNodeMap.
After a added node in the same mutation was successfully appened
we will check whether it has a previous id and the id was pointed
to some nodes in the map, if so, we will insert that node before
it and delete the node from map.
