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.
Confirmed with LO 184.108.40.206 - OS X 10.7.5.
Problem still exists in 220.127.116.11
Still exists in 18.104.22.168
Ubuntu 15.04 x64
LibreOffice 3.3 (inherited from OOo): Works as user expects
LibreOffice 5.1: Does not
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
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Mon Dec 10 01:22:50 2012 +0000
Author: Noel Grandin <email@example.com>
AuthorDate: Fri Jul 13 15:20:39 2012 +0200
Commit: Michael Stahl <firstname.lastname@example.org>
CommitDate: Tue Jul 17 15:33:34 2012 +0200
Convert SV_DECL_PTRARR_SORT(SwDestroyList) to std::set
: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
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.
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 :)
Migrating Whiteboard tags to Keywords: (bibisected)
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=45c8db7ec89978029db2027585da986794971f7c..21dd191b9fd5a75f7633ea27f745a347adb42ae3
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
The bug is still present.
LO 22.214.171.124, Mac OS 10.9.5