Try to produce a clean/sequential DOM walk for the initial snapshot

[eoghanmurray]

I'm detecting a lot of out-of-order-id full snapshots in the wild but find them very hard to recreate (out of order in the sense that ids don't follow a sequential pattern as you walk the snapshot depth first).

The only thing I can imagine is that it has something to do with DOM mutations happening during the snapshotting (so that an already snapshotted DOM node appears later in the walk under another branch of the DOM). The initial commit in this pull request has the effect of fixing the out of order IDs, but maybe it could introduce other problems, so it would be great to get someone else's input on this!

[Juice10]

@eoghanmurray I noticed that whenever rrweb records an iframe that is already loaded it skips a number of ids (which the incremental snapshot then uses to add the iframe's child elements). The fix I added https://github.com/rrweb-io/rrweb-snapshot/pull/78 stops that from happening, as shown in the updated iframe 1 snapshot: https://github.com/rrweb-io/rrweb/pull/568/commits/5948865833d9948a999d7f5acc98f9d6e67cf904# Is this what you are referring to with regards to the out of order ids, or are you referring to something else?

[eoghanmurray]

Don't think there were any iframes in play in the websites I was looking at (and it was prior to the support for nested contexts), just simple mutations.

See also https://github.com/rrweb-io/rrweb-snapshot/pull/61 as a way to discuss the idea of a 'stable' DOM walk, i.e. one that disallows including the same node twice because it has been moved (mutated) from an already-visited spot to a new position.

[eoghanmurray]

Just so it's clear, I now believe this approach can result in duplicate content (with different rrweb ids) in the snapshot — if a node is mutated and moved during the DOM walk from before the current walk position to after it. #61 could be considered the successor to this, although it doesn't propose a solution yet!