I can confirm this for 5.1.1.3 on Linux/x64.

I'm seeing this bug in documents that come out of Microwoft Word, both .doc and .docx format, but also when merging such documents into my own .odt files with the "Compare document" tool.

Example: Let's say the sentence "Mary had a little DOG." was changed to "Mary had a little lamb." The change will show in Writer like this:

> Mary had a little lambDOG.
(with "lamb" as an insertion change and "DOG" crossed out as deletion change)

Now, when I navigate changes with the "Next Change" and "Previous Change" buttons to and reach the insertion of "lamb", the word "lamb" gets selected. I can click "Accept Change", which will accept the insertion of "lamb". But it will then *not* select the deletion change of "DOG", but skip right over it, taking me to the next change in a whole other sentence, leaving the deletion change of "DOG" hanging and forcing me to go back manually.

This also happens when navigating to the "lamb" change and then right-clicking the selected "lamb" change and clicking "Accept Change" in the contect menu.

It does *not* happen when I right-click directly into the word "lamb" without navigating to it with the "Next Change" or "Previous Change" button, in which case the word "lamb" is not selected when I click "Accept Change" in the contect menu.

It also does *not* happen when I place the cursor, with my mouse or keyboard, into the word "lamb", but don't have it selected before opening the contect menu or using the toolbar to select "Accept Change".

MY BEST GUESS as to what happens is this: Whenever the internal "jump to change" mechanism is used and selects a change directly adjacent to another one, accepting (or rejecting!) the thusly selected change skips the adjacent one. It does not happen for all cases when the change was selected in a different, manual way (like selecting with the mouse, placing the cursor etc.).

I can perfectly reproduce this behaviour, so in case you can't follow my clumsy description, I'm willing to make a GIF or something ;)

Hmm, cant trivially reproduce on LibreOffice 5.0.5:

Reproduction steps:
1/ create new text document
2/ press dt<F3> (or bt<F3>) to create dummy text
3/ Edit->Track Changes->Record Changes
4/ add words "foo", "bar" and "baz" at the end of the first three sentences.
5/ save as "changes.odt"
6/ Close and reopen
7/ Edit->Track Changes->Manage Changes
8/ Accept first Change (foo)

Expected and in this case also Observed Behaviour:
Change is accepted and cursor moves to second change (bar).

Maybe attaching a sample document (as simple as possible) would help.

Created attachment 124693 [details]
testcase: .odt with recorded changes

Trivially produced test document. Reproduce the bug like so:

Open document, open "Track changes" toolbar. Place cursor at the beginning of the first sentence. Use the "Next change" button to highlight the first change. Now, either:
1) press "next change" again, or
2) accept the change, or
3) reject the change.

Observe how after any of those actions, the next change is skipped and the one after that is selected.

(In reply to Michael Büker from comment #5)
> Created attachment 124693 [details]
> testcase: .odt with recorded changes
> 
> Trivially produced test document. Reproduce the bug like so:
> 
> Open document, open "Track changes" toolbar. Place cursor at the beginning
> of the first sentence. Use the "Next change" button to highlight the first
> change. Now, either:
> 1) press "next change" again, or
> 2) accept the change, or
> 3) reject the change.

Thanks, with this, I can reproduce this now, however I assume this is a buggy implementation of intended behaviour -- with the above reproduction steps:
a/ using next change jumps first to the dog -> lamb replacement, then to the truck -> farm replacement, then to the there -> here replacement.
b/ accepting the changes works consistent with a/
c/ rejecting a change, rejects the deletion (dog), but does _NOT_ reject the addition (lamb). Movement is consistent with a/ and b/ though.
d/ moving backwards through changes walks over every tracked change separately: so each deletion and insertion is handled individually. This is consistent with the rejection in c/ but not consistent with the movement in c/, nor with the behaviour in a/ and b/

Adding needsUXEval: We need some input on the desired handling of replacements: Should they be handled like one action as per a/ and b/ or as a insertion and a separate deletion as per d/? Keeping this in NEEDINFO until UX has an answer.

The behaviour of c/ is faulty in either case and should be adapted to whatever we want as a concept for replacements.

I am having this same problem with 5.1.3.2 on Ubuntu 16.04.

It's clear to me that skipping a change is not expected behavior, even if two changes next to each other (e.g. a deletion and insertion) might be thought of as a single change. I don't think that question needs to be answered: "next change" should always mean "next tracked deletion or insertion". I'm just a user though.

Playing around with the test document, I notice some really inconsistent behavior. I encounter the skipping the first time through, but if I go back and forth with the next and previous buttons, some of the skipping stops.

In general, where should we give comments to UX?

As a user, I think it would be best to not have any special case for "replacements" as a type of change. I think this important because users will vary in how they replace text in different situations (e.g., some will have insertions before the deletions, some will have deletions before the insertions, some will have insertions, deletions, and more insertions again.)

Please treat every insertion and deletion as a separate change, and move between them sequentially.  I don't mind clicking "accept"/"reject" twice for each replacement; I do mind if I cannot trust which part of the document I am accepting or rejecting in cases where multiple replacements are concatenated. I also mind if I start at the beginning of a document, accept and reject changes to the end of the document, and discover I have not accepted/rejected every proposed change.

(In reply to Buovjaga from comment #9)
> (In reply to kalirren from comment #8)
> > In general, where should we give comments to UX?
> 
> I think this would be pretty efficient:
> https://wiki.documentfoundation.org/Design/Meetings

Feel free to write a ticket about your enhancement requests, the QA team will set keywords appropriately so that the UX people read it. Hi-jacking this bug will most likely end up in the nirvana.
If you are interested you may also read http://user-prompt.com/tracking-changes-with-libreoffice/

(In reply to kalirren from comment #8)
> ...I don't mind clicking "accept"/"reject" twice for each replacement;

Others might be annoyed from the need to accept repeatedly. Do you think your interaction is the average?

(In reply to Björn Michaelsen from comment #6)
> a/ using next change jumps first to the dog -> lamb replacement, then to the
> truck -> farm replacement, then to the there -> here replacement.
> b/ accepting the changes works consistent with a/
> c/ rejecting a change, rejects the deletion (dog), but does _NOT_ reject the
> addition (lamb). Movement is consistent with a/ and b/ though.
> d/ moving backwards through changes walks over every tracked change
> separately: so each deletion and insertion is handled individually. This is
> consistent with the rejection in c/ but not consistent with the movement in
> c/, nor with the behaviour in a/ and b/
> 
> Adding needsUXEval: We need some input on the desired handling of
> replacements: Should they be handled like one action as per a/ and b/ or as
> a insertion and a separate deletion as per d/? Keeping this in NEEDINFO
> until UX has an answer.

The problem is that a change is done with two modifications, delete and add. When I replace McDonald by Trump it adds two entries to the list of changes in the sidebar. The same is true for MS Word where also both operations are shown separately in the sidebar, and I can also accept the deletion but reject the addition. (Deletion is visualized like a comment and the addition inline when the sidebar with all changes is not open.)

Ideally we flag this as _override_ additionally to the pure add and delete. When the user selects a word/paragraph and enters text the change is treated as override and accept/reject are applied at once as expected in this ticket. When the word is deleted first and the replacement added as a follow-up, these steps are done separately and should be stored as such.

If this is not possible I'd rather keep the current behavior because a) it works the same in other word processors, and b) it's safer to click twice.

(In reply to Heiko Tietze from comment #10)
> (In reply to kalirren from comment #8)
> > ...I don't mind clicking "accept"/"reject" twice for each replacement;
> 
> Others might be annoyed from the need to accept repeatedly. Do you think
> your interaction is the average?

I don't find it annoying to accept adjacent additions and deletions in two steps. I think the issue in this bug is just that upon one acceptance, the adjacent change is skipped. 

As there is not currently any "replacement" type of change (only additions and deletions), I disagree that resolving this bug requires any input is as to how to handle replacement changes.

Tracking replacements distinctly from additions and deletions would be an interesting feature, but for me it wouldn't be very useful. I suspect that if were particularly useful to others, Word, Gdocs, and Workshare (doc comparison software popular with law firms) would have already implemented it. Interestingly, Workshare does has a third category beyond additions and deletions: "moves". I don't find it particularly useful though.

(In reply to Andrew Sinclair from comment #12)
> ...Workshare does has a third category beyond additions and
> deletions: "moves". I don't find it particularly useful though.

Why not? You don't delete a full paragraph but _move_ it to some other chapter. Wouldn't be obvious unless the state is correctly set. I'm rather afraid of the correct implementation. Is copy/paste + delete (or vice versa) the same as cut & paste? Not when we follow my suggestion in comment 11, which would be, however,  strange for the user.

(In reply to Heiko Tietze from comment #13)
> (In reply to Andrew Sinclair from comment #12)
> > ...Workshare does has a third category beyond additions and
> > deletions: "moves". I don't find it particularly useful though.
> 
> Why not? You don't delete a full paragraph but _move_ it to some other
> chapter. Wouldn't be obvious unless the state is correctly set. I'm rather
> afraid of the correct implementation. Is copy/paste + delete (or vice versa)
> the same as cut & paste? Not when we follow my suggestion in comment 11,
> which would be, however,  strange for the user.

"Moves" in Workshare seem to be based solely on text similarities. My use case is legal documents. Those tend to use similar wording in multiple places, which leads to false positives (something being shown as a "move" that's really just a common phrase added in one place and deleted from another). Another limitation to their implementation is that text cannot be both moved and edited, so compare results show some part of the text moved and other parts edited. It's generally messy enough not to be useful to me.

(In reply to Andrew Sinclair from comment #14)
> "Moves" in Workshare seem to be based solely on text similarities. My use
> case is legal documents. Those tend to use similar wording in multiple
> places, which leads to false positives (something being shown as a "move"
> that's really just a common phrase added in one place and deleted from
> another). Another limitation to their implementation is that text cannot be
> both moved and edited, so compare results show some part of the text moved
> and other parts edited. It's generally messy enough not to be useful to me.

Accepted. So we should stay with replace or override additionally to add/delete. Devs, is it possible to introduce this state?

I tested this today on:

Ubuntu version 6.0.7.3; and
Mac version: 6.2.8.2

I'm happy to say that the problem seems to be solved. After accepting or rejecting a change now, the cursor remains at the location of the accepted change or rejected change. It doesn't move to the next change at all, so it doesn't skip the next change.

Great, let's close