Created attachment 122108 [details] example file to reproduce bug 1. Open a Spreadsheet with random data in it. 2. Click the Chart button to plot the data. 3. Click in finish 4. Right click inside the chart area and select: Data Ranges 5. Select the "Data series" tab. 6. Select one of the "Data Ranges:" options like "Y-Values" or "X-Values". 7. If you selected "Y-Values", behind "Data Ranges:" you will find "Range for Y-Values" entry. Click the button with an arrow pointing upwards you will find in the right. 8. A little window shows up. Click and drag the cursor over the data to select it. Now the data is surrounded by a purple square. 9. Continue dragging the cursor to the bottom for a few seconds. 10. When you stop, the selected area keeps going down for several minutes reaching the row number 10000 or so. During that time you can not close the window nor the program. You can only kill the program resulting in data loss or wait 15 minutes for the program to stop loosing valuable working time. What do I spect: When I stop dragging the cursor the program stop in selecting rows. What happens: The program keeps going on selecting rows for several minutes without the posibility of saving the work or closing the program.
I can not confirm on win7 Version: 5.2.0.0.alpha0+ Build ID: f4e703aa39e9c294441b6dd86189d8aff32db8bf CPU Threads: 4; OS Version: Windows 6.1; UI Render: default;
I see the reported problem in daily dbgutil bibisect repo version 2016-01-20, so setting status NEW. The problem is absent from bibisect 43all repository oldest version, so setting keyword regression. Some observations ... (*) The uncontrolled looping happens only when I drag the mouse cursor down to at least the task bar. (*) The selection grows faster as I drag the mouse cursor lower. (*) While the uncontrolled loop is in progress, I can move the mouse cursor but I have found nothing that responds to clicks, the desktop responds normally to the keyboard, and soffice is using 95 to 99 percent of a processor. (*) In some versions of LibreOffice, I cannot access the "Data Series" tab of the dialog "Data Ranges" the first time that example.ods is open. If I close the document (discarding changes) and then reopen it from the Start Center, I can follow the rest of the reporter's STR. Working in the bibisect 50max repository, I see from `git bisect bad` ... 18afb8632caa524fbc70ed5ce3808e23e5dad16f # only skipped commits left to test # possible first bad commit: [18afb8632caa524fbc70ed5ce3808e23e5dad16f] source-hash-d05a64df34fd143670cb939b72abfb32d6b714c7 # possible first bad commit: [891b689ba95b9e53609194ee2a1a2d3b8955843c] source-hash-01f406bc28f53acc5a2734af637aa8074a5d1813 ... so setting keyword bibisected. I am omitting the output from `git bisect log` because I accumulated a great number of "skip" results before I found the workaround to get to the "Data Series" tab.
Might have been an issue with the idle handling. Can you try again in master/5.2? I can't reproduce this issue in current master.
In my retest, the program does not crash, but it is still wrong. I am changing summary from "CRASH: Calc hangs when selecting data ranges in chart" to "Calc goes too far selecting range in chart". This observations is from daily Linux dbgutil bibisect repository version 2016-04-02. As I moved the dragging cursor down, the selection appeared to stop at A83. However the program continued for a couple of minutes of high CPU usage, and then the selection was from A1 to A3251.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
I tested again in Ubuntu 16.10 and LibreOffice 5.3.3.2 I used a more powerfull machine and the system blocks completely. I needed to close the program in a virtual terminal. 1st I tested selecting data. With mouse cursor at very bottom the program enters in a loop as @Terrence Enger said. 2nd I tested with "Data Ranges" thing and OS completely froze. I will try to test in Windows.
The bug in not present in Windows 10 but in Ubuntu 14.04 and 16.10 as far as I know.
Tried with gtk2, gtk3 and kde4, but could not reproduce any scrolling problem. Please re-test and hopefully close this. Arch Linux 64-bit Version: 6.1.0.0.alpha1+ Build ID: eeaf6dee2d278eaa037d95a756ad0ffab3314bc2 CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on May 24th 2018
Retested in Ubuntu 18.04 and LibreOffice 6.0.3.2 I can't reproduce the bug anymore. It seems fixed for me.