Download it now!
Bug 125319 - FILEOPEN DOCX Numbered paragraph loses numbering after deleted paragraph in hide changes view
Summary: FILEOPEN DOCX Numbered paragraph loses numbering after deleted paragraph in h...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.4.1 rc
Hardware: All All
: medium normal
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:6.3.0 target:6.4.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Track-Changes
  Show dependency treegraph
 
Reported: 2019-05-16 11:12 UTC by NISZ LibreOffice Team
Modified: 2019-08-01 07:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from Word (19.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-05-16 11:14 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document side by side in Word and Writer with changes shown (87.52 KB, image/png)
2019-05-16 11:14 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document side by side in Word and Writer with changes hidden (106.71 KB, image/png)
2019-05-16 11:14 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2019-05-16 11:12:01 UTC
Description:
Attached document has a deleted paragraph before a numbered one, with change tracking turned on.
When we hide the tracked changes, the paragraph after the numbered one loses the numbering. 
Turning on the display of changes shows the numbering again.

Steps to Reproduce:
    1. Open the attachment
    2. Select Edit – Track Changes – Show to turn off showing tracked changes
    3. The paragraph after the deleted one loses its numbering.
    4. Select Edit – Track Changes – Show to turn on showing tracked changes
    5. The paragraph after the deleted one gets back its numbering.

Actual Results:
The paragraph after the deleted one loses its numbering when changes are hidden.

Expected Results:
The paragraph after the deleted one should keep its numbering.


Reproducible: Always


User Profile Reset: No



Additional Info:
LibreOffice details:
Verzió: 6.2.4.1
Build az.: 170a9c04e0ad25cd937fc7a913bb06bf8c75c11d
CPU szálak: 4; OS: Windows 6.3; Felületmegjelenítés: GL; VCL: win; 
Területi beállítások: hu-HU (hu_HU); UI nyelve: hu-HU
Calc: threaded

Does not happen in: 
Verzió: 6.1.4.2
Build az.: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3
CPU szálak: 4; OS: Windows 6.3; Felületmegjelenítés: GL; 
Területi beállítások: hu-HU (hu_HU); Calc: CL

Bibisect log: 
# bad: [3f78e45c6b5375dcb0c2b26256e2510214fc3670] source sha:26e85974a0287ab5869e7ff0145a66b853d66a02
# good: [ea94942caaf195b8d8b2d5c2abb523359ab390e7] source sha:a20a2d7e0d28658f2d9089da076961a599833a28
git bisect start 'origin/master' 'oldest'
# bad: [93c6fa4266bae1f9aace96b57312aa8f2b1cc327] source sha:4faafea4f24316e75b80e6ef97c1a4d39551a0b2
git bisect bad 93c6fa4266bae1f9aace96b57312aa8f2b1cc327
# good: [6a5b123c97b20147c918b7440fd92f7c92f1a63a] source sha:7bbc1fd443ff0b137206ad279eaed7bd4d5ec6ec
git bisect good 6a5b123c97b20147c918b7440fd92f7c92f1a63a
# bad: [724fa67b9129f003687a6de2f94514d0d43a27b1] source sha:6bbb384bf6334eb9f207f4098820e6852e21325a
git bisect bad 724fa67b9129f003687a6de2f94514d0d43a27b1
# bad: [9cbb4f310d3b2be2061f76beeb0a1785aab84900] source sha:dc10bd5326e4985816d74659ed7d8fded50fe11f
git bisect bad 9cbb4f310d3b2be2061f76beeb0a1785aab84900
# good: [ae7423b3651a39299fcc21b6bf39d9bf44992fba] source sha:c49ea4f3155dcb3538c81734e911eb2910570553
git bisect good ae7423b3651a39299fcc21b6bf39d9bf44992fba
# bad: [e916e5c35c3a1e77512def762d8875bb74d4dccc] source sha:78073ecfdc50e78e3ce094c1259779b7c3b88bc4
git bisect bad e916e5c35c3a1e77512def762d8875bb74d4dccc
# good: [780fc628350f2f69a2537dd28f4db2c4cbb384bd] source sha:8c708b6b1a7f0ee3ba97c0f2270b7f88f0495a15
git bisect good 780fc628350f2f69a2537dd28f4db2c4cbb384bd
# bad: [023f512a0fb6a5516a0d143413b05e99e7bf5a3e] source sha:eb29623cf0614030a61c02b06ccbf06199c4f94e
git bisect bad 023f512a0fb6a5516a0d143413b05e99e7bf5a3e
# good: [f1f5dadf47a54de2bc9af1f7c0f89fdab60e8b40] source sha:87514172c1924492c33a8aa261b082f0ae7f9b48
git bisect good f1f5dadf47a54de2bc9af1f7c0f89fdab60e8b40
# bad: [3c02556c08d543484149b14e3f4747644b79c5fe] source sha:32902f66e7749b2d06d13f50416be5323a0c0ea9
git bisect bad 3c02556c08d543484149b14e3f4747644b79c5fe
# good: [54536eb7095a327d28ef8992e42351e92b278ea8] source sha:5bc7fb209c0e6d7c6a46499d8c2e4d7abaa87bd7
git bisect good 54536eb7095a327d28ef8992e42351e92b278ea8
# good: [e01f0e01d777b202952ab38be74dc92ba8808341] source sha:b310378e874bc8fa7005352fcd85fa64eb075f54
git bisect good e01f0e01d777b202952ab38be74dc92ba8808341
# first bad commit: [3c02556c08d543484149b14e3f4747644b79c5fe] source sha:32902f66e7749b2d06d13f50416be5323a0c0ea9
Comment 1 NISZ LibreOffice Team 2019-05-16 11:14:08 UTC
Created attachment 151449 [details]
Example file from Word
Comment 2 NISZ LibreOffice Team 2019-05-16 11:14:31 UTC
Created attachment 151450 [details]
Screenshot of the original document side by side in Word and Writer with changes shown
Comment 3 NISZ LibreOffice Team 2019-05-16 11:14:51 UTC
Created attachment 151451 [details]
Screenshot of the original document side by side in Word and Writer with changes hidden
Comment 4 Michael Stahl (CIB) 2019-05-16 11:41:47 UTC
in LO 6.0, the result is differently wrong: if you go Show->Hide the document looks different than Word because the last paragraph has no numbering, and then Hide->Show will not restore the last paragraph's numbering

in LO 6.1, the result is differently wrong: if you go Show->Hide the document looks like in Word, but then Hide->Show will apply the last paragraph's numbering to the deleted paragraph, so it's also buggy

so clearly what LO 6.2 does is different from Word, but neither 6.1 nor 6.0 did the same thing as Word; the advantage of 6.2 is that Show->Hide->Show doesn't change the numbering

LO 6.2 looks better than it did in LO 6.0, which is the latest version that doesn't have any sw_redlinehide related changes
Comment 5 Michael Stahl (CIB) 2019-05-16 13:03:49 UTC
i think this is a bit of a corner case with an impedance mismatch.

when you start a deletion in one paragraph, and end in the next one, both Word and Writer will take paragraph formatting from the *start* paragraph, if it remains non-empty after the deletion, but if it becomes empty, then Word will take from the *end* paragraph, while Writer still takes from the *start*

this behavior was apparently introduced in OOo 3.2 with:


commit 4439427aadeaa0cb611011b46f0fa14bfa196f33

    CWS-TOOLING: integrate CWS sw32bf02

    2009-08-20 12:37:32 +0200 od  r275172 : #i100466# correction for showing and hiding redlines



in fact i've already had something like Word's behavior implemented once, due to misreading some code :), but then reverted it at some point...
Comment 6 Michael Stahl (CIB) 2019-05-16 17:21:07 UTC
unfortunately the way how Word does it is to create a separate tracked change for the formatting properties of the last paragraph.

this has some interesting implications: first create a tracked change to join 2 paragraphs without deleting the first one completely, then another deletion to delete the rest of the first one -> first one's formatting wins

do it in one deletion -> second one's formatting wins

Writer's formatting change tracking is not up to the task...

... uploaded some draft patch at https://gerrit.libreoffice.org/72425
Comment 7 László Németh 2019-05-22 14:44:22 UTC
Workaround to show the correct numbering in Hide Changes mode:

https://gerrit.libreoffice.org/#/c/72784/
Comment 8 Commit Notification 2019-05-24 13:10:43 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/cbd894925e6b9869baedcd6476484c14d3a3df87%5E%21

tdf#125319 DOCX track changes: don't change numbering

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 László Németh 2019-05-24 13:18:13 UTC
@Michael: I close this issue based on my workaround, but we all are really interesting in a better solution here. The known problem of the workaround is reported in the Bug 125311. Thanks, László
Comment 10 Michael Stahl (CIB) 2019-05-24 15:07:55 UTC
looks like an okay workaround, except that this m_bFinalizeImport flag can be set not only in Word import filters, which could be a problem...
Comment 11 Xisco Faulí 2019-05-27 12:14:00 UTC
Verified in

Version: 6.3.0.0.alpha1+
Build ID: 53325b40b557cc84d8d21c1baa0ef8d3bfc00ab8
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@László Németh, thanks for fixing this issue!!
Comment 12 Xisco Faulí 2019-05-27 12:24:15 UTC
The fix can't be backported unless https://gerrit.libreoffice.org/#/c/72001/ is backported.
László's call to decide whether to backport it or not
Comment 13 László Németh 2019-05-27 16:46:08 UTC
(In reply to Xisco Faulí from comment #12)

Xisco, Michael: I've made the requested clean-up for the backport: https://gerrit.libreoffice.org/#/c/73043/, I hope, with this, there won't be any obstacle to back port the fixes. Thanks for your help!
Comment 14 Commit Notification 2019-08-01 07:44:04 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/beec1594587d0bf1ea2268f9a435c948b5580278%5E%21

tdf#125319 sw_redlinehide: handle empty paragraphs more like Word

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.