Bug 91912 - BASIC editor / dialogue text fields: Text loses line break when drag-and-dropped; text selection right after drag-and-dropping impossible
Summary: BASIC editor / dialogue text fields: Text loses line break when drag-and-drop...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: Macro-UI
  Show dependency tree / graph
 
Reported: 2015-06-07 03:25 UTC by Johnny_M
Modified: 2022-09-12 10:33 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
gdb from the core file (7.62 KB, text/plain)
2015-06-07 16:47 UTC, Terrence Enger 		Details
Text field test file (press the button to open a dialog with a text field) (10.32 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-05-13 17:10 UTC, Johnny_M 		Details
backtrace with symbols from SIGABRT (11.08 KB, text/plain)
2019-11-16 00:51 UTC, Terrence Enger 		Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Johnny_M 2015-06-07 03:25:11 UTC 
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
Comment 1 Terrence Enger 2015-06-07 16:43:56 UTC 
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.
Comment 2 Terrence Enger 2015-06-07 16:47:32 UTC 
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;
    }
Comment 3 Terrence Enger 2015-06-07 16:48:07 UTC 
Setting keyword have-backtrace.
Comment 4 Johnny_M 2015-06-08 03:25:33 UTC 
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.
Comment 5 Johnny_M 2016-05-13 17:10:23 UTC 
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)
Comment 6 Johnny_M 2016-05-13 18:56:57 UTC 
(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.
Comment 7 QA Administrators 2017-05-22 13:38:34 UTC Comment hidden (obsolete)
Comment 8 Johnny_M 2017-10-03 12:37:35 UTC 
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.
Comment 10 QA Administrators 2018-11-03 03:50:33 UTC Comment hidden (obsolete)
Comment 11 Johnny_M 2018-11-04 14:11:49 UTC 
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
Comment 12 QA Administrators 2019-11-05 03:29:16 UTC Comment hidden (obsolete)
Comment 13 Terrence Enger 2019-11-16 00:51:25 UTC 
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.
Comment 14 Terrence Enger 2019-11-19 16:32:48 UTC 
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.
Comment 15 Andreas Heinisch 2020-05-05 18:10:13 UTC 
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.
Comment 16 Johnny_M 2020-05-10 11:57:52 UTC 
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
Comment 17 QA Administrators 2022-09-04 03:50:23 UTC Comment hidden (obsolete)
Comment 18 Johnny_M 2022-09-12 10:33:09 UTC 
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)