Bug 1438179 - Revision tracking: insertion-deletion couple is not recognized and LO skips over the deletion part
Summary: Revision tracking: insertion-deletion couple is not recognized and LO skips o...
Status: ON_QA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreoffice
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Caolan McNamara
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-01 16:06 UTC by Matěj Cepl
Modified: 2018-04-30 22:15 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-04-14 09:27:41 UTC


Attachments (Terms of Use)
screencast of the issue (317.62 KB, video/webm)
2017-04-01 16:06 UTC, Matěj Cepl
no flags Details
screencast of the current state (819.84 KB, video/webm)
2017-04-15 08:58 UTC, Matěj Cepl
no flags Details

Description Matěj Cepl 2017-04-01 16:06:47 UTC
Created attachment 1268130 [details]
screencast of the issue

Description of problem:
See the situation when going through the revisions in this document. I have a couple <ins>I</ins><del>We</del>. I jump to this couple and LO selects just "I" insertion. When I accept it, it jumps automatically to next revision behind it, so it effectively skips over the deletion of "We".

Version-Release number of selected component (if applicable):
libreoffice-writer-5.0.6.2-7.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Put cursor somewhere before the insertion/deletion couple
2. Jump to the next change
3. Accept change

Actual results:
see above, only the insertion is accepted and cursor jumps to the next pair, effectively skipping over the deletion.

Expected results:
Either LO should recognize the couple as one unit, and accept/reject it as whole, or at least when accepting just insertion/deletion, it should immediately select the member of the pair.

Additional info:

Comment 4 Michael Stahl 2017-04-12 20:19:39 UTC
fixed in upstream master commit 25eb0899227830cca7f28006376962d84f8e9c7a
upstream libreoffice-5-3 for release 5.3.3 commit 644aacd1e4b419f2f85b6c2e18026ca04206b378
upstream libreoffice-5-2 for release 5.2.7 commit 224073a5002df33da673a63db24c19f5a43143c1

added the patch to Fedora f24 and f25

but it is probably a bit late to get it into RHEL-7.4 now

Comment 5 Fedora Update System 2017-04-14 09:23:33 UTC
libreoffice-5.2.6.2-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b10faf327b

Comment 6 Caolan McNamara 2017-04-14 09:27:34 UTC
made this available via CSB experimental repo

Comment 7 Red Hat Bugzilla Rules Engine 2017-04-14 09:27:41 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 8 Fedora Update System 2017-04-15 00:29:01 UTC
libreoffice-5.2.6.2-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b10faf327b

Comment 9 Matěj Cepl 2017-04-15 08:58 UTC
Created attachment 1271775 [details]
screencast of the current state

OK, the situation is certainly better and technically speaking this bug has been fixed, it is now possible to go through text and process revisions just with shortcut keys.

However, it would be even more convenient if LO was able to recognize insert/delete pairs and go through them as such.


Note You need to log in before you can comment on or make changes to this bug.