70fe32b5d2
* The `processMutations` function needed to be bound to the `mutationBuffer` object, as otherwise `this` referred to the `MutationObserver` object itself * Enable external pausing of mutation buffer emissions - no automatic pausing based on e.g. pageVisibility yet, assuming such a thing is desirable https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API - user code has to call new API method `freezePage` e.g. when page is hidden or after a timeout - automatically unpauses when the next user initiated event occurs (am assuming everything that isn't a mutation event counts as 'user initiated' either way think this is the correct thing to do until I see a counterexample of an event that shouldn't cause the mutations to be unbufferred) * Avoid a build up of duplicate `adds` by delaying pushing to adds until emission time * Need to export freezePage in order to use it from rrweb.min.js * Add a test to check if mutations can be turned off with the `freezePage` method * I noticed out of order ids (in terms of a DOM walk) in a FullSnapshot. A DOM mutation was executed against the mirror asynchronously before it could be fully processed. This would lead to a situation in replay where a mutation is executed against a DOM tree that already has the mutation applied. This changeset fixes that by freezing any mutations until the snapshot is completed. * Remove attribute modifications from a mutation event that were incorrect in that they were repeating the attributes of those nodes present in the 'adds' array of the same mutation * I've manually verified that this empty text node is actually removed when the dropdown is opened: document.getElementById('select2-results-1').childNodes NodeList(2) [li.select2-results-dept-0.select2-result.select2-result-selectable.select2-highlighted, li.select2-results-dept-0.select2-result.select2-result-selectable] and also that it is not reinstated after the second `await page.click('.select2-container');` * Rearrange when removal happens in order to satisfy tests. I'm also reverting a recent test change (2600fe7) so that tests pass after this rearrangement; I believe that test change to still be the correct way of doing it, but maybe it is not strictly important that there are extra mutations on attributes of just added nodes * As mutations are now paused during FullSnapshots, we shouldn't be counting this as a 'user emission'. We automatically emit mutations after unpause anyway ('emit anything queued up now') * Ensure that we clear arrays before emitting, as the mutation could have the side effect of triggering a FullSnapshot (checkoutEveryNth), which would otherwise re-trigger emission of same mutation (through the new pause/fullsnapshot/mutationemit/unpause process) * Don't let the programattic pausing during TakeFullSnapshot accidentally unpause a manual call to the API method `freezePage` * Rename paused -> frozen for consistency and change to use getter/setter access methods
rrweb
I have joined Github Sponsors and highly appreciate your sponsorship.
rrweb refers to 'record and replay the web', which is a tool for recording and replaying users' interactions on the web.
Currently, rrweb has already solved many difficult problems in recording and replaying, but the data structure may still be changed before the release of Version 1.0. So please be cautious to use rrweb in the production environment.
Guide
📚 Read the rrweb guide here. 📚
Project Structure
rrweb is mainly composed of 3 parts:
- rrweb-snapshot, including both snapshot and rebuilding features. The snapshot is used to convert the DOM and its state into a serializable data structure with a unique identifier; the rebuilding feature is to rebuild the snapshot into corresponding DOM.
- rrweb, including two functions, record and replay. The record function is used to record all the mutations in the DOM; the replay is to replay the recorded mutations one by one according to the corresponding timestamp.
- rrweb-player, is a player UI for rrweb, providing GUI-based functions like pause, fast-forward, drag and drop to play at any time.
Roadmap
- rrweb
- handle cross-domain request errors
- record in web worker
- implement transmission data compression
- verify recording in mobile browser
- rrweb-player
- implement efficient progress bar drag and drop control
- add full screen mode
- extensions
- hijack the console API and record corresponding events
- hijack Ajax/fetch API and record request events
- use TraceKit to log exception events
Internal Design
Contribute Guide
Since we want the record and replay sides to share a strongly typed data structure, rrweb is developed with typescript which provides stronger type support.
- Fork the rrweb component repository you want to patch.
- Run
npm installto install required dependencies. - Patch the code and pass all the tests.
- Push the code and create a pull request.
In addition to adding integration tests and unit tests, rrweb also provides a REPL testing tool.
Who's using rrweb
