This report is somewhat a spin-off of tdf#159214 or tdf#160044, which were originally set as solved as a duplicate of tdf#160036. The original problematic behavior has returned again, but under different conditions, so I am opening this new report. Another dupe of tdf#160036 is tdf#159751, but I have not re-tested it yet. When moving any content in a selected set of cells around with drag and drop, the border of the destination cells was shown in real time to indicate where the content would be placed at the end of the drag and drop operation. In a recent LO 24.8 alpha, this border is not displayed anymore, making it unclear/unknown where exactly the data you are moving will be placed. STR: 1. Select a range of cells. 2. Click on the selected area and hold the mouse button. 3. Drag the selection > there is no border/line indication to where the selected area should arrive, as it used to be. 4. (Optional) repeat the same drag on LO 24.2.2.2 and see the expected border/line that marks the to-be-destination area. While dragging, whichever combination of keys is simultaneously used (e.g. to either move or copy the selection), the expected "destination" border/line is not seen. In the original reports I cited above, the problems were seen only on Windows with Skia/Raster, particularly when "Use Skia for all rendering" was ENABLED. When the setting was DISABLED, I used to be unable to reproduced the problem in the past. But now I can replicate the problem again, whether "Use Skia for all rendering" is enabled or not. I can also see the problem in LO Safe mode. I have _not_ reset my settings. I cannot reproduce the problem in LO 24.2.2, nor in LO 7.6.5. I have not tested with LO 24.2.3 nor with LO 7.6.6. Reproduced with either of the following conditions: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a895ec4205659038aa95941b65715fed1a3e7be CPU threads: 4; OS: Windows 10 (10.0 build 19045); UI render: default; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a895ec4205659038aa95941b65715fed1a3e7be CPU threads: 4; OS: Windows 10 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded
Reproducible with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a895ec4205659038aa95941b65715fed1a3e7be CPU threads: 16; OS: Windows 11 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.8$. Adding Cc: to Noel Grandin ; Could you possibly take a look at this one? Thanks 018c3bf2a3803eba0ca425cdb68b3ea3397fd2ca is the first bad commit commit 018c3bf2a3803eba0ca425cdb68b3ea3397fd2ca Author: Jenkins Build User <tdf@maggie.tdf> Date: Tue Apr 23 18:57:08 2024 +0200 source 1f86fdd4b5428a8c7b253051cca93429dc71f894 166543: tdf#160787 Calc active cell cursor has small transparent corners | https://gerrit.libreoffice.org/c/core/+/166543
On 2024-05-29 with LO 24.8 alpha, this problem was still present. This seems to be solved as of 2024-06-02 with LO 24.8 alpha, probably by tdf#161322 comment 3: 302a221856809e2b046cb9fb1675bfff4d86a37d tdf#161198 tdf#161322 fix selection overlays <https://gerrit.libreoffice.org/c/core/+/168253>