Description: LibreOffice will hang when moving a few columns using drag and drop. Feels like a follow up of bug 113530 Steps to Reproduce: 1. Open the file found here: https://yadi.sk/i/rM9QctDym5y3M 2. Select columns A-C 3. Left click and drag everything two columns to the right (content of column A will be in C) -> hang Actual Results: Hang Expected Results: No hang Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.1.0.0.alpha0+ Build ID: cc1db6f2b0ebe05ae807628778835b62df00eca2 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-12-02_23:45:34 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
I can reproduce it in Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 but not in Version: 4.1.0.0.alpha1+ Build ID: a2c9d4f8bbde97f175bae4df771273a61251f40 so I'd see it was introduced by multi_type_vector refactoring. Closing as dupe of bug 109339 *** This bug has been marked as a duplicate of bug 109339 ***
Repro in libo-master64~2018-04-24_23.06.21_LibreOfficeDev_6.1.0.0.alpha0_Win_x64 and libo-master~2018-04-25_00.27.22_LibreOfficeDev_6.1.0.0.alpha0_Win_x86.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dennis Francis committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f28b5586a7af4456bc087318961c46ad727af324%5E%21 tdf#114245 : Let both ScDocument::CopyToDocument()... It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 151443 [details] test file
it takes 25 seconds in Version: 6.3.0.0.alpha1+ Build ID: a3e649c3384d19a5ad540c3d65d5f79b66fd9090 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded with the commit included, pretty much the same as in Version: 6.2.5.0.0+ Build ID: 6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded so I can verify the hang is gone in LibreOffice 6.2 and 6.3, but I don't see difference with or without Dennis' commit
@Dennis, what time do you get before your commit ?
(In reply to Xisco Faulí from comment #6) > it takes 25 seconds in > > Version: 6.3.0.0.alpha1+ > Build ID: a3e649c3384d19a5ad540c3d65d5f79b66fd9090 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > with the commit included, pretty much the same as in > > Version: 6.2.5.0.0+ > Build ID: 6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > so I can verify the hang is gone in LibreOffice 6.2 and 6.3, but I don't see > difference with or without Dennis' commit Are you sure ? My master is at 7c88700b74346d58084b48656f1c7e28f891cf09 (few weeks old). Without my patch the drag-drop does not finish even in 3 minutes, and I did not wait and killed it. With my patch the drag-drop finishes in 6 to 7 seconds. I'm using a non-debug-build because debug/dbgutil-builds should not be used to measure performance. Version: 6.3.0.0.alpha0+ Build ID: 74a7b890524af4a52e711d8f0793ce844ded0948 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: en-US (en_US.utf8); UI-Language: en-US Calc: threaded Note that threading does not affect the performance here.
ohh, wait a minute, my tests were wrong, I was dropping it in column D, not it column C, now I see the hang before your commit, great!! Thanks for fixing this issue. It can't be backported because it depends on 169a1b542165f3444791fd6e672d56d3fe48bd66. Besides, lubos is working on further changes. This issue has been around for quite some time. we can wait a bit more...