Bug 160946 - In Calc, when moving content with drag and drop, destination area is no longer shown
Summary: In Calc, when moving content with drag and drop, destination area is no longe...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+ Master
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Cell-Selection Drag-and-Drop
  Show dependency treegraph
 
Reported: 2024-05-06 06:05 UTC by ady
Modified: 2024-05-08 00:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ady 2024-05-06 06:05:16 UTC
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
Comment 1 m_a_riosv 2024-05-06 12:10:24 UTC
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
Comment 2 raal 2024-05-06 15:38:14 UTC
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