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
Created attachment 105646 [details] Test document used to reproduce the issue
(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)
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.
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
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.
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.
** 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.0.0.5 or later) https://www.libreoffice.org/download/ 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
[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.
** 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 https://www.libreoffice.org/download/ 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
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.
Fixed the most problematic 4a) case, keeping the state of the tracked deletion.
*** Bug 106380 has been marked as a duplicate of this bug. ***
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.
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
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
(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.