Bug 83419 - EDITING: Autocorrect doesn't work correctly with visible tracked changes
Summary: EDITING: Autocorrect doesn't work correctly with visible tracked changes
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All All
: high minor
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords:
Depends on:
Blocks: Track-Changes AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2014-09-03 00:38 UTC by Matthew Francis
Modified: 2021-02-26 07:30 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


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

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 4.3.1.2 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>"

or

4b) type "knwon<space>"


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

Actual results:
On 4.3.1.2:
(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 4.3.1.2 release

So the behavior related to 4.3.1.2 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 4.3.1.2 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:
New
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 3.5.7.2 in order to get rid of 'preBibisect' version as 3.5.7.2 looks to be the last version not covered by bibisect-43all.
Comment 9 Xisco Faulí 2017-09-29 08:48:32 UTC Comment hidden (obsolete)
Comment 10 Commit Notification 2020-11-05 07:30:12 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ac84cf7dda4a5150ff23e112ee16f00b8de8ec7c

tdf#83419 sw change tracking: fix bad autocorrect

It will be available in 7.1.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 11 László Németh 2020-11-05 07:41:03 UTC
Fixed the most problematic 4a) case, keeping the state of the tracked deletion.
Comment 12 László Németh 2020-11-05 13:41:39 UTC
*** Bug 106380 has been marked as a duplicate of this bug. ***
Comment 13 Commit Notification 2020-11-09 14:59:27 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2951c96bcb673a260a09e2c6eb92ca0f99bf0c18

tdf#83419 sw change tracking: clean-up autocorrect

It will be available in 7.1.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 14 NISZ LibreOffice Team 2020-12-03 15:02:48 UTC
Verified in:

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa
CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: hu-HU
Calc: threaded
Comment 15 pierre-yves samyn 2021-02-17 11:14:37 UTC
Hi

(In reply to Commit Notification from comment #13)
> László Németh committed a patch related to this issue.
> It will be available in 7.1.0.

It doesn't work in my environment for AutoCorrections with : (colon) 

Platform: Windows & Version: 7.1.1.1 (x64) / LibreOffice Community
Build ID: 575c5867c4cc13d7ae78f9ce39a54a52ed38c769
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: threaded

Steps to reproduce:

1. File> New> Text document
2. type :--: 

Expected & actual result ok (:--: replaced by –)

3. Edit> Track changes> Record
4. type :--: 

No replacement

On the other hand the other AutoCorrection works (e.g. __a )

This was ok with Version: 7.0.4.2 (x64)
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: en-US
Calc: threaded

Best regards
Comment 16 NISZ LibreOffice Team 2021-02-26 07:30:49 UTC
(In reply to pierre-yves samyn from comment #15)
> Hi
> 
> (In reply to Commit Notification from comment #13)
> > László Németh committed a patch related to this issue.
> > It will be available in 7.1.0.
> 
> It doesn't work in my environment for AutoCorrections with : (colon) 
> 

Hi Pierre-Yves

That is a regression from the second patch here. I just filed it as a separate ticket for that.

Thanks for testing and noticing it!

I set this bug back to fixed, since this is a new problem.