Tested via the snippet below and it seemed to work, though the id recorded was -1 (maybe thats correct?), so I was a bit confused:

https://codesandbox.io/s/beautiful-babbage-hz2wj

{"type":3,"data":{"source":8,"id":-1,"adds":[{"rule":"p{color: red;\n}","index":0}]}

Here's the full output from repl: https://gist.github.com/dcramer/3b8449cf4388663ab7f0c1dbec399fe6

Aside - willing to help try to get test coverage in for replays (beyond just testing the controller actions), but didn't see any existing.

Interesting.

The example in the gist works because it captures the added DOM:

{
  "source": 0,
  "texts": [],
  "attributes": [],
  "removes": [],
  "adds": [
    {
      "parentId": 4,
      "previousId": 52,
      "nextId": null,
      "node": {
        "type": 2,
        "tagName": "style",
        "attributes": {
          "_cssText": "p { color: red; }"
        },
        "childNodes": [],
        "id": 53
      }
    }
  ]
}

The replayer code looks fine.

I believe the id: -1 happens because of the async callback of MutationObserver.

Looks like the order of the dynamic stylesheet insertion is:

1. create a <style> element
2. call insertRule on the style element

But the order of rrweb's observer callback is:

1. Capture the insertRule calling, because it triggered in sync.
2. Capture the add of <style> element, because MutationObserver will fire in the next async loop.

I'm not sure whether this works for all the CSS in JS lib, it seems the first insertion will be replayed by the add of DOM, and the following insertion weill be captured correctly.
But I think put the insertRule observer callback into a macro task(maybe by using setTimeout(, 0)) will help us always get the right order.

Seems like it’d be nice to ignore insertRule until the style is on the dom. Thoughts? Not sure how complex that’d be. Seems like it’d save some bandwidth on payload size.