Download it now!
Bug 83419 - EDITING: Autocorrect doesn't work correctly with visible tracked changes
Summary: EDITING: Autocorrect doesn't work correctly with visible tracked changes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: high minor
Assignee: Not Assigned
Depends on:
Blocks: Track-Changes AutoCorrect-Complete
  Show dependency treegraph
Reported: 2014-09-03 00:38 UTC by Matthew Francis
Modified: 2019-10-24 06:52 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Test document used to reproduce the issue (9.38 KB, application/vnd.oasis.opendocument.text)
2014-09-03 00:38 UTC, Matthew Francis
Possibly related backtrace from assertion (65.50 KB, text/plain)
2014-09-03 14:27 UTC, Matthew Francis

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-09-03 00:38:14 UTC
Observed on OSX 10.9.4/ LO and 4.4 master

Deleted text shouldn't be considered during autocorrection, but is when tracked changes are made visible.

Steps to reproduce:

1) Open the attached test document
2) Set tracked changes off, and view tracked changes on
3) Position the cursor after the deleted "k"

then either

4a) type "nwon<space>"


4b) type "knwon<space>"

Expected results:
(4a expected) -> Nothing
(4b expected) -> The typo is corrected

Actual results:
(4a actual) -> The deleted "k" is promoted to live text and the whole word corrected to "known"
(4b actual) -> The typo is not corrected

On 4.4 master:
(4a actual) -> The deleted "k" is promoted to live text and the whole word corrected to "Known"
(4b actual) -> The deleted "k" is promoted to live text and the whole word is mis-corrected to "Kknown"

In each case, the results are correct if Edit – Changes – Show is disabled
Comment 1 Matthew Francis 2014-09-03 00:38:59 UTC
Created attachment 105646 [details]
Test document used to reproduce the issue
Comment 2 Matthew Francis 2014-09-03 00:49:32 UTC
(although the above case seems obvious to me, figuring out the correct behaviour with/without tracked changes enabled when the deletion is in the middle of a word is left as an exercise for the reader. Using the attached test document, the behaviour of "am(deleted k)es<space>" -> "Kmakes" in 4.4 master is definitely not the right answer however)
Comment 3 Joel Madero 2014-09-03 07:30:26 UTC
Bodhi 2.x
LibreOffice release

So the behavior related to has always been around and I'm not sure it's a bug. Personally I find it to be pretty useful that it knows that you want the letter to not be deleted - this intuitively makes sense to me.

I also see the same behavior with 4.4 built just a couple days ago - I don't see a kknown result.

So all in all I'm not convinced that this is a bug - I see different results in 4.4 - and the behavior of has been around for years.

Awaiting a follow up before closing this as NOTABUG.
Comment 4 Matthew Francis 2014-09-03 08:56:55 UTC
There may have been some confusion about when "tracked changes" should have been on/off in the previous comments, and who the edits are by. Apologies if so; please allow me to restate.

In general, when tracked changes are enabled, I don't believe it should make a difference to the behaviour of autocorrect whether changes are visible or not. It's a matter of convenience only to see or not see the edits, and in either case, when tracked changes are enabled, the changes of an earlier Person A should not be randomly modified by a subsequent person B (this is a requirement of a workflow of which I am often part, where changes are accepted by a later Person C who needs the full history)

Upon further checking, it seems that it makes a difference whether or not the word in question is at the start of the line. Perhaps spelling autocorrection, auto-capitalisation and tracked changes are tripping over one another?

In a fresh build (today) of 4.4 master, with tracked changes on and visible, from the start of the line,
[Note: The deleted character should have been deleted by another user]

1) "am(deleted k)es<space>" -> "Kmakes" (incorrect - wrong correction and broke another user's edit)
2) "A am(deleted k)es<space>" -> "A (deleted k)makes" (correct)
3) "(deleted k)nwon<space>" -> "Kknown" (incorrect - wrong correction and broke another user's edit)
4) "A (deleted k)nwon<space>" -> "A (deleted k)known" (arguably incorrect - should have ignored the other user's edit)
5) "(deleted k)knwon<space>" -> "Kknown" (incorrect - wrong correction and broke another user's edit)
6) "A (deleted k)knwon<space>" -> (no change) (incorrect - should have ignored the other user's edit and corrected)

(4) and (6) are a pair to me - the other user's edit should have been ignored for autocorrect purposes in both cases
Comment 5 Matthew Francis 2014-09-03 14:27:49 UTC
Created attachment 105685 [details]
Possibly related backtrace from assertion

One more: on master,

i) Starting with the attached document, position the cursor after the "k" with tracked changes enabled and visible.
ii) Type "asd fgh"
iii) Undo all the way
iv) Redo all the way

The attached assertion failure occurs after (iv). Given that at this point, the initial "k" no longer appears as a change at all (either addition or deletion), which is an undo inconsistency, I suspect that this may be related.
Comment 6 Joel Madero 2014-09-03 20:10:56 UTC
Okay convinced that this is indeed a bug - 

Marking as:
Minor - while it's quite visible - it does not prevent per say high quality work, but it can definitely slow you down.
High - this isn't even associated with spelling a word right, if you just type ;akdjg;askjf after the (deleted)"k" and push enter the k becomes live. So basically any time you add to a deleted word/letter that is currently awaiting to be rejected or accepted it.

Interestingly enough - this has been around for a LONG time. Pre-Bibisect updating version.
Comment 7 QA Administrators 2015-09-04 02:47:47 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2016-09-14 15:45:02 UTC
[This is an automatic message]

Changing version to in order to get rid of 'preBibisect' version as looks to be the last version not covered by bibisect-43all.
Comment 9 Xisco Faulí 2017-09-29 08:48:32 UTC
** 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 on a currently supported version of LibreOffice 
(5.4.1 or 5.3.6

If the bug is present, please leave a comment that includes the version of LibreOffice and 
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave 
a short comment that includes your version of LibreOffice and Operating System

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)

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:

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team