Description: 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 24.2, this border is not displayed anymore, making it very difficult to guess where exactly the data you're moving will be placed. Steps to Reproduce: 1.Open a new Calc document. Insert any data in any group of contiguous cells 2.Now select the cell where you inserted your data, place the mouse pointer within the selected cells, and drag them to move content to some other place in the spreasheet 3.During the drag, you see the mouse pointer, but the border of the destination cells is not shown anymore, making it difficult to guess where exactly the dragged content will end up being placed. Actual Results: Using drag and drop of cells content is awkward since you do not see clearly where your data will be dropped. Expected Results: This is a regression: until 7.6.3 the border of the selected cells you dragged around was displayed so that you easily knew where they would be dropped when releasing the mouse button. This is the correct functionality. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.1 (X86_64) / LibreOffice Community Build ID: b4d45829793cddfe67b58a53f495528c75738d8a CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: it-IT (it_IT); UI: it-IT Calc: threaded
Works for me Version: 24.2.0.1 (X86_64) / LibreOffice Community Build ID: b4d45829793cddfe67b58a53f495528c75738d8a CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded But doesn't work with skia/raster Version: 24.2.0.1 (X86_64) / LibreOffice Community Build ID: b4d45829793cddfe67b58a53f495528c75738d8a CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded regression from Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Yes you're right: if I disable Skia Rendering the problem diasappears. However, since without Skia navigation of large spreadsheets is awfully slow, as a workaround I found that enabling - Use Skia for all rendering but disabling - Force Skia software rendering the navigation speed in spreadsheets is OK and the drag and drop shows its destination; so I have adopted such configuration (a.k.a. "Skia/Vulkan")
FWIW... Quoting from tdf#158167 comment 13 posted on 2023-11-27: > Since the introduction of 16384 columns in LO 7.4, there seems to be some > (minor?) additional lag when moving a row (in comparison to LO 7.3), but the > lag is _much_ more notable in LO 24.2. > > Additionally, until LO 7.6, while moving the selected row/area (dragging the > mouse but before releasing the button) we can see an edge/border indicating > the destination area of the move. In contrast, in LO 24.2, such border over > the to-be-destination area (either an entire row or any other selected > area/cell) is not seen (although my 24.2 alpha is several weeks old ATM, so > YMMV). > > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: c0c8cffd3541e3cd616c96791b04e7ebf2b2ed03 > CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: > win > Locale: en-US (es_AR); UI: en-US > Calc: CL threaded I have not re-tested (on newer alpha) since then.
I also don't see destination border when moving cells. Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: en-US Calc: CL threaded
Let's not keep waiting for some bibisect just to CC the UX Team. The problem is already known for a couple of months now at least, so it should not had been allowed to get to 24.2.0 final; and yet, we are there and the problem persists. D&D is such a common procedure in Calc that this report should had been much higher in importance and/or priority, because of its impact and visibility for common users. There is no need for Devs discussion. Common users need this issue solved ASAP, because no Calc user would agree to use Calc in such condition, and not _that_ many users will investigate how to work around this issue by fiddling with settings, especially when prior versions worked as expected with default settings. CC'ing Heiko.
I agree that proper feedback for DnD is important. A bit surprising that it might be related to Skia (don't get feedback on macOS with or without Skia with 7.6.4). Hope the regression is not caused by Sahil's work on the col/row highlighting.
Confirming the issue on Windows related to Skia, also on Linux (VCL=gen and Skia on/off). It's definitely unrelated to the col/row highlighting but Skia.
(In reply to Heiko Tietze from comment #7) > Confirming the issue on Windows related to Skia, also on Linux (VCL=gen and > Skia on/off). It's definitely unrelated to the col/row highlighting but Skia. Would it be possible for this issue to get a higher priority/importance (not only in the fields in this report)? TIA. (Unfortunately, there are enough reports about DnD not being user-friendly enough in Calc already without this regression.)
(In reply to ady from comment #8) > Would it be possible for this issue to get a higher priority/importance... Xisco?
Attachment 192960 [details] is a screenshot of the problem from dupe tdf#160044. IDK how many times users will have to report this (aka dupes) until someone will increase the importance/priority and actually do something about it. I know there are lots of other things to do too.
*** Bug 160044 has been marked as a duplicate of this bug. ***
Wordks with "UI render: default": Version: 24.2.0.3 (x86) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: es-MX (es_MX); UI: es-ES Calc: threaded Do not work with "UI render: Skia/Raster" (with or without Force Skia software rendering): Version: 24.2.0.3 (x86) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: es-ES Calc: threaded
I am adding "Skia" to the Summary. Perhaps it would help move this report forward.
This seems to have begun at the below commit in bibisect repository/OS win64-24.2. Adding Cc: to Noel Grandin ; Could you possibly take a look at this one? Thanks 7d56051a3adc746e523c45602895e3c4414a705d is the first bad commit commit 7d56051a3adc746e523c45602895e3c4414a705d Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Jul 16 02:48:13 2023 -0700 source f8c15850dbfaa46605e1e353ae1f49e69184e8a1 154223: update skia to m116 | https://gerrit.libreoffice.org/c/core/+/154223
I must add (it could be considered another bug, but it is strictly correlated) that while disabling the sub-option "Force Skia software rendering" avoids the problem (I can leave "Use Skia for all renderings" enabled and still see the destination borders for cells drag and drop), the above sub-option seems to behave quite erratically, in the sense that after you disable it (but not "forse skia for all render"), it becomes enabled for time to time without any intervention by the user... Difficult to reproduce, but this happened to me at least 4-5 times in the last two weeks using LO daily. So the invisible destination borders reappeared and I had to repeat the disabling workaround over and over. Before, when I had both options and sub-option enabled, I had never experienced this strange behaviour: they remained enabled reliably all the time unless the user acted to the contrary.
A user at the LibreOffice subreddit just ran across this too: - https://www.reddit.com/r/libreoffice/comments/1bmbbxr/what_happened_to_the_drag_and_drop_preview_box_in/ - - - I confirmed bug in my normal install too. DOES NOT WORK: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded WORKS: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Difference is "UI render": - Skia/Raster = bad - Skia/Vulkan = good - - - I also confirm Comment 2. TEMPORARY WORKAROUND In Calc, go into: - Tools > Options - LibreOffice > View - Under "Graphics Output" - UNCHECK the box for "Force Skia software rendering". - - - - - - - - STEPS TO REPRODUCE In Calc, using some basic data: Letters | Num A | 1 B | 2 C | 3 1. Left-Click on A. 2. Hold SHIFT. 3. Left-Click on 3. 4. Let go of SHIFT. 5. Hold ALT. 6. Left-Click+Hold on the highlighted data + Drag mouse elsewhere. Expected: During Step 6: - A (black) 2x3 box showing where you are going to "drop" the data. Actual: During Step 6: - No box shows.
I have just tested in LibreOffice 28.8.0.0.alpha0 Nightly build Win-x86_64@tb77-TDF 2024-03-23 03:49:07 and selection when dragging is fixed thanks to accessibility bug https://bugs.documentfoundation.org/show_bug.cgi?id=160036
*** This bug has been marked as a duplicate of bug 160036 ***