Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull changes from rrweb-io/rrweb #2

Merged
merged 51 commits into from
Jan 20, 2021
Merged

Pull changes from rrweb-io/rrweb #2

merged 51 commits into from
Jan 20, 2021

Conversation

joris
Copy link

@joris joris commented Jan 20, 2021

No description provided.

eoghanmurray and others added 30 commits October 4, 2020 20:54
* 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
* add failing test

* add stylesheet to dom to manipulate the rules

* cleanup
Loop the append queue has been proved to be very inefficient, and
some times lead to N^2 time complexity.

Especially when some abnormal data could not be appended into the
real DOM, will make a dead loop.

Previously we use a 5000ms time out to handle this, which is not
user-friendly and not explicitly.

In this patch, we transform the queue into a tree data structure,
which reflects the layout of real DOM. With the tree data structure,
we can find whether there are dangling nodes that need to be dropped.
Also, the iteration will be much more efficient.

There is still a 500ms time out to avoid a dead loop, but should not
be called in expected scenarios.
* add yarn.lock to CI

* update travis config

* replace data url by placeholder in CI
…io#410)

fix a potential bug: handleResize function might change the display style of mouseTail
…t handling for the first full snapshot can be added straight after constructor. See rrweb-io#216 (rrweb-io#416)
…c time) (rrweb-io#426)

applyScroll function should be called after all of new nodes mounted on dom
…playback is paused (rrweb-io#428)

set pauseAnimation to true by default
…"virtual parent" optimization (rrweb-io#427)

* fix: elements would lose some state like scroll position because of "virtual parent" optimization

* refactor: the bugfix code

bug: elements would lose some state like scroll position because of "virtual parent" optimization

* fix: an error occured at applyMutation(remove nodes part)

error message:
Uncaught (in promise) DOMException: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node
YunFeng0817 and others added 21 commits November 29, 2020 18:12
…b-io#424)

* wip: working on rrweb logger

* wip: can record and replay some simple log

* wip: can record and replay log's stack

* wip: try to serialize object

* wip: record and replay console logger

hijack all of the console functions.
add listener to thrown errors

* wip: record and replay console logger
add limit to the max number of log records

* feat: enable rrweb to record and replay log messages in console

this is the implementation of new feature request(issue rrweb-io#234)

here are a few points of description.
1. users need to set recordLog option in rrweb.record's parameter to record log messages.  The log recorder is off by default.
2. support recording and replaying all kinds of console functions. But the reliability of them should be tested more
3. the stringify function in  stringify.ts needs improvement. e.g. robustness, handler for cyclical structures and better support for more kinds of object
4. we can replay the log messages in a simulated html console like LogRocket by implementing the interface "ReplayLogger" in the future

* improve: the stringify function

1. handle cyclical structures
2. add stringify option to limit the length of result
3. handle function type

* refactor: simplify the type definition of ReplayLogger
* docs: add document for console recording and playback

* docs: adjust some sentences
Bumps [ini](https://github.com/isaacs/ini) from 1.3.5 to 1.3.8.
- [Release notes](https://github.com/isaacs/ini/releases)
- [Commits](npm/ini@v1.3.5...v1.3.8)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…is finished (rrweb-io#445)

plus: fix the problem that sometimes return value of getCurrentTime() is negative
Fix broken link to design docs
* Update to fflate

* Update docs, bundler config
…b-io#454)

I noticed 8 or 10 of these events being generated in a multi-tab browsing session on Chrome 87.0 on Win10.  I'm speculating they were generated as a side effect of changing tabs but I can't recreate
@joris joris merged commit 3121dfe into master Jan 20, 2021
@joris joris deleted the rrweb-io-master branch January 20, 2021 13:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.