Description: Using Shift+F3 or the corresponding toolbar shortcuts changes the letter case correctly, however these changes are not properly recognized as changes made by the user and recorded. If a word has been changed from lower to uppercase manually, the original letters are struck out and the new ones added and underlined. If the upper and lowercase letter are selected and UPPERCASED with the shortcut function, all the lowercase struck-out letters will be uppercased. Steps to Reproduce: Example 1 1. Type "sample" into a new document. 2. Activate 'Record Changes'. 3. Select 'm'. 4. Format > Text > UPPERCASE. Example 2 1. Type "sample" into a new document. 2. Activate 'Record Changes'. 3. Select 'm'. 4. Type 'M'. 5. Select "SamMple". 5. Format > Text > UPPERCASE. Actual Results: Example 1 "saMple" But without the colored/struck-out lowercase m and uppercase M is not colored/underlined. Example 2 "SAMMPLE" What should be 'm' and the following 'M' still have the correct decoration indicating the recorded changes but the first 'm' is now uppercase. The rest of the letters do not have the proper decoration. Rejecting the change results in "SAMPLE". Expected Results: Example 1 "samMple" (m colored and struck-out, M colored and underlined) Example 2 "samMple" (m colored and struck-out, M colored and underlined) then "sampleSAMPLE" ("sample" colored and struck-out, "SAMPLE" colored and underlined) Reproducible: Always User Profile Reset: No It also happens on a different computer. Additional Info: The same inconsistent behavior happens with text tables and in Calc spreadsheets cells. The changes act the same through undo/redo cycles. The info box that pops up when hovering over a changed spreadsheet cell also shows the same incorrect information. This behavior changes depending weather I select the cell and change the case or double click then select just the text and change the case. It looks like the program doesn't consider changes made by the Change Case functions to be done by the user, so they are not recorded when they should be. May be related to Bug 106380. Also exists in and old copy of OpenOffice 4.1.2 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Repro. Inherited per: (In reply to Brian from comment #0) > Also exists in and old copy of OpenOffice 4.1.2 Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: db17a874af37350b3270932175854ee674447bc1 CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on August 11th 2017
** 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! Warm Regards, QA Team MassPing-UntouchedBug
Still present in Version: 6.1.0.3 (x64) Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 Additional thought: The Auto Correct behavior should also be checked for it's interaction. It would make sense to me for any automatic changes to be considered as changes made by the user.
*** Bug 122115 has been marked as a duplicate of this bug. ***
*** Bug 130028 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/2d3c77e9b10f20091ef338e262ba7756eb280ce9 tdf#109266 sw change tracking: track transliteration 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