Bug 61832 - Incorrect spellcheck of words with recorded changes shown
Summary: Incorrect spellcheck of words with recorded changes shown
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks: Spell-Checking
  Show dependency tree / graph
 
Reported: 2013-03-05 05:27 UTC by haim kilov
Modified: 2022-03-11 00:42 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Zipped folder with the odt and screenshot of the problem (21.94 KB, application/zip)
2013-03-05 05:27 UTC, haim kilov 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description haim kilov 2013-03-05 05:27:11 UTC 
Created attachment 75937 [details]
Zipped folder with the odt and screenshot of the problem

When recorded changes are shown, corrected correct words are flagged as incorrect. When these changes are not shown the spellcheck is correct.

This bug apparently is new (does not exist in OpenOffice).

See the screenshot.
Comment 1 Emir Sarı 2013-03-05 15:17:57 UTC 
Confirmed with LO 4.0.1.2 - OS X 10.7.5.
Comment 2 almos 2013-12-04 19:56:20 UTC 
Problem still exists in 4.1.3.2
Comment 3 almos 2014-12-06 13:48:14 UTC 
Still exists in 4.3.3.2
Comment 4 Joel Madero 2015-07-04 18:50:11 UTC 
Findings:
Ubuntu 15.04 x64

LibreOffice 3.3 (inherited from OOo): Works as user expects
LibreOffice 5.1: Does not

But: 

I am relatively sure this is how our competitor works also so the change *might* have been on purpose. If you haven't accepted the change yet then the system assumes you won't (vs. assuming you will). I tend to agree with the reporter but would like ux-advise to see what they think as this would change the experience for a lot of people who may like the current setup (dealing with default/user preference experience is always hard).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa is the first bad commit
commit 66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon Dec 10 01:22:50 2012 +0000

    source-hash-21dd191b9fd5a75f7633ea27f745a347adb42ae3
    
    commit 21dd191b9fd5a75f7633ea27f745a347adb42ae3
    Author:     Noel Grandin <noel@peralex.com>
    AuthorDate: Fri Jul 13 15:20:39 2012 +0200
    Commit:     Michael Stahl <mstahl@redhat.com>
    CommitDate: Tue Jul 17 15:33:34 2012 +0200
    
        Convert SV_DECL_PTRARR_SORT(SwDestroyList) to std::set
    
        Change-Id: Ifbee6942045b26fc7df8fb96d910197f77729b4b

:100644 100644 13d66368624db1158439984d29b9b6b4e382edc1 a0cb51fd961ac7c36664039de46e9568c5ccba18 M	autogen.log
:100644 100644 ab5cb173d26c712f4f0b3768b20921326a298faf 4d71a655ba9c7f4367fa0ad343c3d3fca21db58d M	ccache.log
:100644 100644 b673e1e2d524aa0ac5ea208305aa72d64ef75e85 e6d7c27a36ce4105db810fbff826d9b862fcba46 M	commitmsg
:100644 100644 701af077bfba9dbd53e4ed300daafc1c6853fd95 dc8ff3e836892bf5ce91d3fa29c2b9f7f4cfe162 M	dev-install.log
:100644 100644 5a022646e5d271579c529aec4f74867fbd84cd35 83db6377e3f2405d20c058544be4f2b918852266 M	make.log
:040000 040000 348fa0564620b55634dd0ae025b5068fc79c7a0f 8b7b928585f6981c6de6516b99173e72362469c4 M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327
# good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect good 369369915d3582924b3d01c9b01167268ed38f3b
# good: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7
git bisect good 6fce03a944bf50e90cd31e2d559fe8705ccc993e
# good: [da317333e5675622f55c9dda17396c659af65320] source-hash-15af925c254f27046427de70a59011e2ac3d6bdb
git bisect good da317333e5675622f55c9dda17396c659af65320
# bad: [18518588d8414f446ece5591944766f5082ebef5] source-hash-82c25249e624cb54ca6d3293d1c3d0d8ebc208e0
git bisect bad 18518588d8414f446ece5591944766f5082ebef5
# bad: [89740762f0af849e492932bd71e59149cdcd5a00] source-hash-06f20d73da21342046a480a6b22af69901351328
git bisect bad 89740762f0af849e492932bd71e59149cdcd5a00
# bad: [66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa] source-hash-21dd191b9fd5a75f7633ea27f745a347adb42ae3
git bisect bad 66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa
# good: [0f0c47e3376b69f432cbbc1a16b7f0006d748ca4] source-hash-45c8db7ec89978029db2027585da986794971f7c
git bisect good 0f0c47e3376b69f432cbbc1a16b7f0006d748ca4
# first bad commit: [66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa] source-hash-21dd191b9fd5a75f7633ea27f745a347adb42ae3
Comment 5 haim kilov 2015-07-04 20:33:33 UTC 
I respectfully disagree with the comment by Joel.

The (most important) purpose of recording changes is to demonstrate these changes to other authors/editors/proofreaders of the file. If a file has only a single author/editor/proofreader then he will most probably make the changes without explicitly showing them.

When the changes are explicitly shown, it is important to demonstrate to everyone that the corrections are, well, correct.

I have encountered this problem with my co-authors who were less than happy with the flagging of corrected corrections.
Comment 6 Joel Madero 2015-07-04 20:36:52 UTC 
But I agreed with you ;) I just said it "might" have been done on purpose (by others who disagree with our stance). Thus why I requested UX input. I am almost sure that MSO works the same way as I've hit annoying "bugs" because of the issue (interacting with macros weird) and their devs say "it's how it's designed." Not saying that we shouldn't "fix it" but it really comes down to preference, after triaging thousands of bugs, I can guarantee that others disagree with our position :)
Comment 7 Robinson Tryon (qubit) 2015-12-13 11:09:26 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2018-09-14 02:46:12 UTC Comment hidden (obsolete)
Comment 10 haim kilov 2018-09-14 03:40:41 UTC 
The bug is still present.

LO 6.0.5.2, Mac OS 10.9.5
Comment 11 QA Administrators 2019-09-15 02:47:03 UTC Comment hidden (obsolete)
Comment 12 haim kilov 2019-09-16 01:19:10 UTC 
The bug is still present. 

Mac OS 10.12.6, LO 6.3.1.2
Comment 13 Xisco Faulí 2020-03-09 13:28:30 UTC 
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Comment 14 QA Administrators 2022-03-10 03:43:57 UTC Comment hidden (obsolete)
Comment 15 haim kilov 2022-03-11 00:42:03 UTC 
Resolved - Worksforme

LO 7.3.1.3

Mac Catalina 10.15.7