https://bugs.documentfoundation.org/show_bug.cgi?id=95357

Björn Michaelsen <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needsUXEval
            Summary|When accepting a Change the |Change tracking
                   |cursor skips the next       |movement/action are
                   |change                      |inconsistent for
                   |                            |replacements

--- Comment #6 from Björn Michaelsen <[email protected]> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to