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.
Also move the addHoverClass implementation into the rebuild stage.
So if there is still some corner case we have not handled, it will
only affect the replayer part of rrweb.
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.
