Description: Track changes color coding inconsistent; moved has sometimes the same color as deleted Steps to Reproduce: 1. Open attachment 180483 [details] 2. Tools -> Options -> Make sure user date being empty (close dialog with OK) 3. Enable track changes: Edit -> Track changes -> Record (show changes should be enabled) 3. Select the "six" in the first line 4. Backspace -> Text strike through, yellow (expected) 5. Select "ways" next to six in the first line 6. CTRL+X 7. CTRL_V -> Strike through, yellow -> UN-expected (reference: step 8-10) 8. Select "idolatry" in the first line 9. CTRL+X -> Text strike through, yellow (expected) 10. CTRL+V -> Text strike through, green (expected) 11. Press CTRL+Z once -> Text strike through, green (UN-expected, expected yellow) Actual Results: Moved gets the color coding of deleted Expected Results: Proper color coding Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 7a89eae97a970939174d59aa58147eaa194acaee CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
>7. CTRL_V -> Strike through, yellow -> UN-expected (reference: step 8-10) I got the green color in this step Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 41139aa86ecbb4c34e9996eb0f95a194b8eb0771 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded possibly mac only problem?
(In reply to Roman Kuznetsov from comment #1) > >7. CTRL_V -> Strike through, yellow -> UN-expected (reference: step 8-10) > > I got the green color in this step > How did you select "six" "ways" in step 3/5? I used double click in both cases (forgot to mention this before)
(In reply to Telesto from comment #2) > (In reply to Roman Kuznetsov from comment #1) > > >7. CTRL_V -> Strike through, yellow -> UN-expected (reference: step 8-10) > > > > I got the green color in this step > > > How did you select "six" "ways" in step 3/5? I used double click in both > cases (forgot to mention this before) The same method
I will check it again, maybe a build glitch
The same with TDF master build (previously was my own build) Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: c1c8ce3b0f1037bca4d500af2f39363cd9d38db6 CPU threads: 8; OS: Mac OS X 12.3.1; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
confirm in macOS Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: c1c8ce3b0f1037bca4d500af2f39363cd9d38db6 CPU threads: 4; OS: Mac OS X 12.4; UI render: Skia/Metal; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Lazslo, you made many changes in this area in last time. Could you please look at it?
Telesto, can you please check if this was resolved by the fix for bug 149388?
(In reply to Stéphane Guillou (stragu) from comment #7) > Telesto, can you please check if this was resolved by the fix for bug 149388? I guess so. I should have added a screenshot for the previous state. It's still not totally fine though, I think. All modification are shown in yellow. There is no color coding; feels off. I need to check it on a Windows machine for comparison. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aef28c23adc87b8e26eacb56c7dbcf652e907fb9 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded FWIW: I assume it to be bug 149388; however didn't carefully check.. so that's why opted for WFM. Feel free to change it
(In reply to Telesto from comment #8) > It's > still not totally fine though, I think. All modification are shown in > yellow. There is no color coding; feels off. I need to check it on a Windows > machine for comparison. I think that's the expected default for addition vs deletion. Underline and strikethrough are used to differentiate between them. However, is a move also yellow, i.e. when drag-and-fropping a text selection to a different location? That should be the dark green one. > FWIW: I assume it to be bug 149388; however didn't carefully check.. so > that's why opted for WFM. Feel free to change it Makes perfect sense, thank you!
(In reply to Stéphane Guillou (stragu) from comment #9) > However, is a move also yellow, i.e. when drag-and-fropping a text selection > to a different location? That should be the dark green one. A change is only registered as: Insert or delete as far my testing goes. I'm unable to create change which registers as 'move' in LibreOffice (drag drop is registered as deletion and insertion). The sample document shows an 'move' but no clue how to do that (no recent version of MSO at hand for testing) This isn't specific for Mac, also happening on Win. Regarding to the color scheme. I still find it odd that empty user data the insertion color being yellow on Mac and blue on Windows. I would somewhat expect the same behaviour across all system environments (already for the sake of testing).
(In reply to Telesto from comment #10) > A change is only registered as: Insert or delete as far my testing goes. I'm > unable to create change which registers as 'move' in LibreOffice (drag drop > is registered as deletion and insertion). The sample document shows an > 'move' but no clue how to do that (no recent version of MSO at hand for > testing) It is inconsistent for me too. A drag-and-drop will sometimes result in addition/deletion in yellow, sometimes in a dark green move. Might need a new report for that. > Regarding to the color scheme. I still find it odd that empty user data the > insertion color being yellow on Mac and blue on Windows. I would somewhat > expect the same behaviour across all system environments (already for the > sake of testing). Probably better to track that in bug 149953.