Created attachment 170660 [details] Example file from Writer This is a followup to bug #109266 When change tracking is enabled and Format – Text – Cycle Case is selected (or Shift+F3 is pressed) twice, the selection is lost after the first change, so cycling the case of the selected text becomes impossible. In non-change tracking mode the selection is not lost and the selections case changes correctly. Steps to reproduce: 1. Open attached document. 2. Select the first sentence and push Shift+F3 twice Actual results: The selected texts case changes, it is recorded as tracked change, but the selection is lost. Expected results: The selection is not lost and it’s possible to change the case again. LibreOffice details: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 78c33a4c3d1633b97049874305b3b49b820395a2 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL
Created attachment 170661 [details] Screenshot of the problem in Writer
I confirm it with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7cd5b35caa8d4fa9d0ba2b2c6ce4b88726ed2be6 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
The bug is still present in this version of LO: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: df3b95a39472e18ea8acdaae447b7176e37a9256 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
This bug is also present in this version of LO: Version: 7.1.0.0.alpha1+ (x64) Build ID: 738bcf5e9a8c443d60c29c3a8068e8c16c72638a CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded But after 4 pushes of shift + F3.
After 10 pushes of shift + F3, the bug is still not present in this version of LO: Version: 7.0.0.0.alpha1+ (x64) Build ID: 574c57090642347980d2395e1e183cc7b5c171ad CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded
The bug is present in this version of LO: Version: 7.1.8.0.0+ (x64) / LibreOffice Community Build ID: a94b58277c7aeaa83ce14347cd0b8f7137969d03 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded So a bibisection can be done in the repository cd win64-7.1.
The result of the bi-bisection: source 2d3c77e9b10f20091ef338e262ba7756eb280ce9
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dc748d7dbd114fbf663752258dbaf003af2926c3 tdf#141198 sw: fix cycle case with change tracking It will be available in 24.2.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.
Commit description: tdf#141198 sw: fix cycle case with change tracking Fix cycle case with change tracking by rejecting changes of the word, and setting the cursor inside the original word. Previously the cycle case resulted only in a tracked deletion and tracked insertion, putting the text cursor at after the word, so it was not possible to cycle on the different cases e.g. by pressing Shift-F3 multiple times (and moving the text cursor inside the tracked insertion didn't help, because resulted in broken text at asking for the next cycle). A regression from commit 2d3c77e9b10f20091ef338e262ba7756eb280ce9 "tdf#109266 sw change tracking: track transliteration".
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/985015195007ee236e62254bc5685816f7e4ec5a tdf#141198 sw: fix cycle case with change tracking It will be available in 7.6.3. 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.
Hi. I've been studying this report today to create a testcase (my first one) but I found the following difficulties and I have some notes I would like to share: 1) Irrelevant or not, we should start by asking ourselves where that `Shift-F3` shortcut came from. The shortcut is there, next to `Format`>`Text`>`Cycle Case` but it is not in the documentation. - This is the documentation for LO 7.6 Writer: https://help.libreoffice.org/latest/en-US/text/swriter/04/01020000.html?DbPAR=WRITER#bm_id3145763 - And this is 6.2 (Writer too): https://help.libreoffice.org/6.2/he/text/shared/04/01010000.html?DbPAR=SHARED#bm_id3149991 - If you're wondering, here is the docs for OOo (it's not there either): https://wiki.openoffice.org/wiki/Documentation/OOoAuthors_User_Manual/Writer_Guide/Shortcut_keys_for_OpenOffice.org_Writer And it works, however when tracking is enabled things fall apart. But just under certain circumstances, and that is when changes are made on changes that have not been accepted or rejected. (See section 3) 2) Perhaps we are misinterpreting changes tracking functionality with undo/redo. Personally I think I need to open the discussion to this before suggesting a test case. - An author creates a document and saves an initial text ("This is the initial text") - The document is saved, Track changes is then enabled, and the document is saved again. - A different author opens the document, adds a change (capitalizes "initial"), and saves the document. - So far no one has approved or rejected the proposed changes. - Note that at this point initial should be -initial-_Initial_, meaning -initial- colored/struck-out lowercase, and _Initial_ colored/underlined. - A new author opens the document and adds changes to the word "initial" (to uppercase) and saves the document. - Important note: There might be a disclaimer from the person opening this Report (or any of you) but the change (apply uppercase to the word) should be applied to the word, not to the word and its previous state. - The original author opens the document and see the proposed changes. The expected result should be the following: This is the -initial-_-Initial-__INITIAL_ text where -xxx- means colored/struck-out _xxx_ means colored/underlined - Also, the information about the changes from the different authors should be shown on the `Manage Changes` sidebar. I would like to know your opinion to start with this. For the disclaimer in particular (mentioned in the step by step) because that could lead to no-errors-found but users could still be opening bug reports for this. 3) As mentioned in section 1 and 2, the issue is still happening when changes are applied to marks of changes instead of the resulting changed word (which has no errors, not in my screen at least). I will attach the document I made as example and I will wait for your approval on this to proceed with the testcase.
Created attachment 190275 [details] Should a unit-test expect this results This file has a line which has been edited by different authors. This document is in some way waiting for approval to proceed with the creation of the test case or request more information, or just determine that other person would do the the test case
As it was pointed out by Buovjaga on IRC, I was missing the scope of this bug report, it's about the text selection being lost (I was more focused on the parent/related report). I will comment if I get something to upload or discuss
Was there a change in the intention here? With the committed change, the selection is still lost after cycling case twice as was in the description. László, NISZ: can you comment on this?
(In reply to Buovjaga from comment #14) > Was there a change in the intention here? With the committed change, the > selection is still lost after cycling case twice as was in the description. > > László, NISZ: can you comment on this? The main problem was the lost cycle, now this is solved for a single word. For a bigger selection, Bug 157667 was created.
This fixed only the cycle case of the word under the text cursor (i.e. without selecting the word). For the selected word, a new issues was filed, see Bug 157988. (Its fix is under testing: https://gerrit.libreoffice.org/c/core/+/158666).
(In reply to László Németh from comment #16) > This fixed only the cycle case of the word under the text cursor VERIFIED with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2b84c860b591457da4c995435f9ca7ce5c7b3d23 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded László, thanks for fixing it!
(In reply to Dieter from comment #17) @Dieter: thanks for the verification and feedback! @Federico: thanks for your detailed feedback! During analysis of the problem set, I've found also a freezing, fixed in Bug 157937. There are still corner cases, which need more investigation, but the most frequent problems were fixed.