When (one or more) complete lines of text are marked in the BASIC editor and then dragged-and-dropped with the mouse to a new location within the same file, they loose the final line break. Test procedure: 1. Write several lines of text in the BASIC editor (accessed via macro editing from within a Calc spreadsheet) 2. Mark one or several full (i.e. including the final line break) lines 3. Using the left mouse button, drag and drop the marked text into another location within the same file Expected results: 3. All lines are moved including their final line breaks, like in any other text editor Actual results: 3. The last line (or the one line, in case it's just one) loses it final line break. (Which is quite annoying.) Notes: - The bug does not occur if the same marked text (on the above step 3) is moved using cut-and-paste via keyboard shortcuts (CTRL-X and CTRL-V) or the mouse context menu. - Neither does the bug occur when the same marked text is dragged-and-dropped into another application - e.g. the default OS text editor, the terminal window, etc. - But it DOES occur as well when the same marked text is dragged-and-dropped into LibreOffice Writer. OS: Linux Mint 17.1 (based on Ubuntu 14.04 LTS), 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 LO (4.4.3.2): ppa:libreoffice/libreoffice-4-4
I see the reported problem on Windows Vista in LibreOffice verson ... Version: 5.1.0.0.alpha1+ Build ID: 2da066628f02925ade2590229eb069d4765f619a TinderBox: Win-x86@39, Branch:master, Time: 2015-06-07_00:10:24 Locale: en-CA (en_CA) and on debian-wheezy in ... LibreOffice 3.5.4.2 Build ID: 350m1(Build:2) so I am setting status NEW, O/S All, and version 3.5.4.2.
Created attachment 116352 [details] gdb from the core file In LibreOffice dbgutil version 2015-06-07, the program crashes with messages ... /usr/include/c++/4.8/debug/vector:346:error: attempt to subscript container with out-of-bounds index 14, but container only holds 14 elements. Objects involved in the operation: sequence "this" @ 0x0x2802bf0 { type = NSt7__debug6vectorIP13TEParaPortionSaIS2_EEE; }
Setting keyword have-backtrace.
That was fast, thanks! One more observation: After the above drag-and-dropping, it is not possible to immediately start selecting a text again. Which is counter-intuitive. Instead, it is first necessary to click anywhere in the text and only then does selecting become possible again. Test procedure (following the one in the bug description; although it is not necessary to select complete lines - any text drag-and-drop on step 3 is enough to reproduce the bug): 4. Click and hold the left mouse button anywhere in the text, then move the mouse to select a text portion. Expected results: 4. Text gets selected. (Like with any other text editor.) Actual results: 4. The cursor gets placed where clicked but stays there - i.e. it doesn't follow the mouse to select the text portion. Only on the subsequent attempt is a selection possible. Also, I could reproduce all issue steps in the LO 4.3.5 release on WinXP 32 bit. So, I'm going to change the processor to "All" as well.
Created attachment 125039 [details] Text field test file (press the button to open a dialog with a text field) The same issue (all four steps) also occurs in text fields on dialogues (opened from within BASIC). I guess that the same kind of editor is used for both, the BASIC code editor and those text fields. Re-confirming the issue (in both, BASIC editor and dialogue text fields) on 32-bit Debian Jessie with: Version: 5.2.0.0.alpha1+ Build ID: db729f3b685fd832a3ec7387b339cf2bbeb4bd4d CPU Threads: 2; OS Version: Linux 4.3; UI Render: default; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-05-13_00:37:45 Locale: en-US (en_US.UTF-8)
(In reply to Johnny_M from comment #5) > The same issue (all four steps) also occurs in text fields on dialogues > (opened from within BASIC). I guess that the same kind of editor is used for > both, the BASIC code editor and those text fields. And it also occurs in the following: - The label text entry field under File -> New -> Labels -> Label text - The file comments field under File -> Properties -> Description Additionally, the test step 4 ("text selection right after drag-and-dropping impossible", see comment 4) fails with the following (although steps 1 to 3 pass): - Comments in Writer documents - The formula editor (in its bottom pane) Tested with the above Version: 5.2.0.0.alpha1+, as well as with following on 64-bit Linux Mint 17.1: Version: 5.0.6.2 Build ID: 1:5.0.6~rc2-0ubuntu1~trusty1 Locale: de-DE (en_GB.UTF-8) So, I'm changing the affected component to "UI", since more than one is apparently affected.
** 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
Fully reproducible (including comments 4 to 6) with: Version: 6.0.0.0.alpha0+ Build ID: 892c719fffa06de4c7aeab497326cad7bae9e5c6 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-27_03:02:09 Locale: en-US (en_US.UTF-8); Calc: group The only difference now seems to be on drag-and-dropping (or copying using Ctrl+C) into Writer: The first, instead of the last, line break is lost (the target content gets inserted there) and Undo breaks if only two lines are pasted.
https://opengrok.libreoffice.org/xref/core/basctl/source/basicide/baside2.hxx?r=81ced402#78 https://opengrok.libreoffice.org/xref/core/vcl/source/edit/textview.cxx#1919
** 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
Fully reproducible (including comments 4 to 6) with (on Ubuntu Mate 18.04.1 liveUSB): Version: 6.2.0.0.alpha1+ Build ID: 726c18db3215ec74135f51365322a6b531f328af CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-03_19:38:55 Locale: en-US (C.UTF-8); Calc: threaded Except, following of the comment 6 seems to have been fixed - it no longer shows the issue: - The label text entry field under File -> New -> Labels -> Label text
Dear Johnny_M, 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
Created attachment 155866 [details] backtrace with symbols from SIGABRT I still see the reported behaviour in bibisect-linux-64-6.4 source-hash 498c2d39 (2019-11-07) running on debian-buster. A local --dbgutil build of source-hash 80ee721c still fails with message /usr/include/c++/8/debug/vector:417: Error: attempt to subscript container with out-of-bounds index 14, but container only holds 14 elements. in the terminal upon the "drop" operation. Backtrace attached. I am marking my backtrace from 2015-06-07 obsolete.
I can no longer reproduce the index-out-of-bounds crash, even when I rebuild commit 498c2d39. I do not know what is different. After moving lines in the Basic IDE and then undoing the moves, I observe anomolies in the caret positioning and syntax highlighting. I do not know that these anomolies are relevant, and they are too small to warrant a separate bug report.
I tried to reproduce the drag and drop problem in the BASIC editor and I cannot reproduce the error in: Version: 7.0.0.0.alpha0+ (x64) Build ID: dbd74393fd0b4d11655e2c4d2676ec1bfebe8923 CPU threads: 6; OS: Windows 10.0 Build 17134; UI render: Skia/Vulkan; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: CL However, I can reproduce the the problems in comments 4 to 6.
I can reproduce comments 1 to 6 with following on Ubuntu 19.10 liveUSB: Version: 7.0.0.0.alpha1+ Build ID: 71c4f7d68586fa84a55a78560448ff09a3a46a21 CPU threads: 4; OS: Linux 5.3; UI render: Skia/Vulkan; VCL: gtk3; Locale: en-US (C.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-05-09_09:49:33 Calc: threaded The only difference is that the issue no longer occurs at all (neither the text move issue, nor the subsequent selection issue) in the following stated in the comment 6: - The label text entry field under File -> New -> Labels -> Label text - The file comments field under File -> Properties -> Description
Dear Johnny_M, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Same as on comment 16 with following on Ubuntu 22.04 liveUSB: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 4ca5c021c91680f1a5df47225d9cb0d41c0a8637 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded The only difference is that drag-and-dropping is no longer possible at all with the following stated in the comment 6: - Comments in Writer documents - The formula editor (in its bottom pane)