Age | Commit message (Collapse) | Author |
|
|
|
rather than replacing all except the last letter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
need this anymore
|
|
|
|
|
|
does not change; only curIndex is increased. Newlines are counted
between curIndex and the end of string.
|
|
3354b9406b94e1a04b5eee1c0152914dde73ba89
the first part is always false so the second part which is always true
in case a cs deleted some lines was never triggered...sigh
|
|
newlines in op.chars
|
|
Conflicts:
src/static/js/Changeset.js
|
|
|
|
This reverts commit 22803da42f4f8c6aeccc15d0a916bae6332a8652.
|
|
|
|
|
|
|
|
|
|
Some files are obviously external libraries, I didn't touch them
|
|
Fix a whole range of bugs related to corrupted changesets
|
|
|
|
|
|
THE BUG - HIGH LEVEL:
- When client A sends out an attribute change, client B applies that change to itself but
also thinks that it made the change itself, which is incorrect. This means that when client B
next makes a change, he will send out that he made the attrib change that A actually made.
- Ex: Have 2 clients on the same pad. Have A apply bold on some text. Next, have B type a character.
B will broadcast that it both added a character AND applied bold, when in reality it did NOT
apply bold at all, that change was done by the other client and this client incorrectly adopted it as its own.
- This root bug behavior results in clients continuing to think that they each made the other client's change,
thus resulting in an infinite loop of changeset spamming that bogs down clients and harms server stability.
THE BUG - IN DEPTH:
- The root issue is in the way that Changesets are combined in Changeset.follow(). Specifically, in the case of a
changeset with ONLY new attrib changes (no text changes) being merged with an identity changeset (has no ops).
- In this case, Changeset.follow() copies the ops of the new CS and fully overrides the other CS.
- applyChangesToBase invokes Changeset.follow to determine the final client document CS state after applying the new CS.
If the final client document CS state is NOT the identity CS, then the client broadcasts that it made a change.
- When client A changes just attribs, client B's applyChangesToBase calls Changeset.follow() and passes client A's
changeset (attrib change) and Client B's current changeset state (identity).
- As per the noted bug, Changeset.follow() returns client A's changeset as a result, causing client B to adopt
client A's changeset as its own document state. Thus, client A ends up thinking it has made client B's changes.
THE FIX:
- Changeset.follow() should NOT copy the ops of the new CS passed in if those changes are only attrib changes.
This allows applyChangesToBase to properly set the client's CS back to the identity after applying an
external attrib change, instead of incorrectly adopting the external client's changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
node/server.js
src/static/js/Changeset.js
src/static/js/ace.js
src/static/js/ace2_common.js
src/static/js/ace2_inner.js
src/static/js/broadcast.js
src/static/js/changesettracker.js
src/static/js/chat.js
src/static/js/collab_client.js
src/static/js/contentcollector.js
src/static/js/domline.js
src/static/js/linestylefilter.js
src/static/js/pad.js
src/static/js/pad_connectionstatus.js
src/static/js/pad_docbar.js
src/static/js/pad_editbar.js
src/static/js/pad_editor.js
src/static/js/pad_impexp.js
src/static/js/pad_modals.js
src/static/js/pad_savedrevs.js
src/static/js/pad_userlist.js
src/static/js/pad_utils.js
src/static/js/timeslider.js
src/static/js/undomodule.js
src/static/pad.html
src/static/timeslider.html
|
|
Resolved conflicts:
.gitignore
src/static/js/ace.js
src/static/js/ace2_inner.js
src/static/js/broadcast.js
src/static/js/domline.js
src/static/pad.html
src/static/timeslider.html
Ignored conflicts (please merge manually later):
node/server.js
src/node/utils/Minify.js
|
|
etherpad
|
|
|