* Add a `slimDOM` option to strip out unnecessary parts of the DOM in terms of replay
- <script> tags in the <head> take up unnecessary storage space and are often injected semi randomly to become a source of unnecessary variation between recordings of the same thing
- comment tags can be stripped out without affecting display
- future: this option could also turn on more aggressive stripping, e.g. elements that are hidden by CSS (assuming we can handle them becoming visible after mutation events)
* Mark nodes ignored due to slimDOM option, so that they can also be ignored by the mutation observer in rrweb
* Introducing the `ignored` attribute violates the `serializedNodeWithId` type
* slimDOM: Strip out whitespace nodes from <head> element as they have no effect but take up space
- these would otherwise have to be merged after <script> elements are removed; for statcounter usecase, removing
<script> elements is no good if there is still a trace of their presence due to the white space (and hence a variant <head> node is still produced)
- I explored a more radical stripping of all white space nodes, but there is a problem if parent node is <pre> or otherwise rendered with `white-space: pre` and similar.
detecting applied styles with getComputedStyle would be very expensive (I haven't measured it though)
* Export IGNORED_NODE as a constant instead of relying on the hard-to-grok `-2`
* Remove <link rel=preload as=script> which are similarly as useless as <script> tags
* Make slimDOM configurable with the expecations that `slimDOMOptions: true` will only enable non-destructive options (so not all options may be turned on)
* Expand slimDOM to add options to remove more elements from the <head> that should not be necessary in the replayer context
* 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
- was making this change for <wix-image> on Wix websites, but discovered after that this has already been done in e4593ff76d
- have tested document.createElement('wix-image') and document.createElement('foo_bar'), but can't find a canonical source for what is allowed in tag names.
- this restriction was originally introduced in #150 to prevent document.createElement('alt=""') i.e. a very malformed tag name
This issue was originally reported in #280 but may also relate
to #167 and other potential performance issues in the recording.
In #206 I implemented the new mutation observer which will defer
the serialization of DOM, which helps us to have a consistent DOM
order for the replay.
In this implementation, we use an array to represent the `addQueue`.
Whenever we need to consume the queue, we will iterate it to make
sure there is no dead loop, and then shift the first item to see
whether it can be serialized at the new timing.
But this implementation may be very slow when there are a lot of newly
added DOM since it will do an O(n^2) iteration.
For example, if we have three newly added DOM `n1`, `n2`, `n3`,
the iteration looks like this:
```
[n1, n2, n3]
n1 -> n2 -> n3, consume n3
[n1, n2]
n1 -> n2, consume n2
[n1]
n1, consume n1
```
We should have a better performance if te iteration looks like this:
```
[n1, n2, n3]
n3, consume n3
[n1, n2]
n2, consume n2
[n1]
n1, consume n1
```
Simply reverse the mutation payload does not work, because it does
not always as same as the DOM order.
So in this patch, we replace the `addQueue` with a double linked list,
which can:
1. represent the DOM order in its data structure
2. has an O(1) time complexity when looking up the sibling of a list item
3. has an O(1) time complexity when removing a list item
