Bug 113998 - Moving a bulleted list entry up/down also moves the subsequent text line
Summary: Moving a bulleted list entry up/down also moves the subsequent text line
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 114888 123148 (view as bug list)
Depends on:
Blocks: Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2017-11-22 22:34 UTC by Frank Brütting
Modified: 2023-05-05 18:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen cast (86.83 KB, image/gif)
2017-11-22 22:35 UTC, Frank Brütting
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Brütting 2017-11-22 22:34:06 UTC
Description:
See my appended screen cast. I just created a second level header via "Ctrl + 2" after a bulleted list, and moved one item up.

Steps to Reproduce:
See above.

Actual Results:  
Subsequent header gets moved.

Expected Results:
Subsequent header shouldn’t get moved.


Reproducible: Always


User Profile Reset: No



Additional Info:
It does not happen every time, seems to happen due to how the subsequent header is created. In my example I pressed "enter" two times at the end of the second bullet item, so that I exited the bulleted list. Then I entered the text and pressed "Ctrl + 2".


User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Frank Brütting 2017-11-22 22:35:13 UTC
Created attachment 137928 [details]
Screen cast
Comment 2 Dieter 2017-11-23 20:25:27 UTC
I confirm it with 

Version: 6.0.0.0.alpha1 (x64)
Build ID: c1d1f859b268f650143d48f294999cda0fa57350
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: group

It seems to me like the second header is treatened like a subpoint.
Comment 3 Frank Brütting 2018-01-07 22:00:21 UTC
*** Bug 114888 has been marked as a duplicate of this bug. ***
Comment 4 Telesto 2018-01-30 15:59:31 UTC
STR
1. Open attachment 138944 [details] (bug 114888)
2. Move “bla” (with sub-entries) up.

Also found in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 5 Telesto 2018-01-30 16:02:48 UTC
Also in
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5
Comment 6 QA Administrators 2019-01-31 03:48:11 UTC Comment hidden (obsolete)
Comment 7 Frank Brütting 2019-02-03 18:01:03 UTC
Still not fixed in 6.1.4.2
Comment 8 Dieter 2021-01-21 21:51:41 UTC
WORKSFORME in

Version: 7.0.4.2 (x64)
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 9 Justin L 2021-05-03 14:15:35 UTC
repro 7.2+
I used the document and steps to reproduce from comment 4. When I move "bla" up with subpoints, "Heading" follows along with them. (This makes some sense. "Bla" is at listLevel 1, while "Heading" is a Heading 2, which is listLevel 2.)

So, what SHOULD happen here?  Should we ONLY move items up and down through the same numbering rule? But currently we can even move through normal paragraphs, so that would be a huge change. Our current method is very non-complex and therefore flexible - any list grouping can move up one "paragraph" regardless of the content.

But I suppose it wouldn't be too hard to add an "if belongs to the same numbering rule" when deciding whether to include a line as a sub-point or not. [The problem with doing this is that it is VERY dependent on styles, while most people just use the toolbar, and might intentionally mix and match bullets/numbering to make sub-points.]

If lcl_GotoNextPrevNum from docnum.cxx compares 
-           if( pRule )
+           if( pRule && pRule->IsAutoRule() == pOrigRule->IsAutoRule())
then I get the requested result. But that looks like a rather scary change that wouldn't just necessarily affect moving with subpoints. (Nor is "autoRule" documented, so I don't know exactly what that really is.)
Comment 10 Justin L 2021-05-04 06:34:15 UTC
->IsOutlineRule() is probably a better test in this situation. And yet, ultimately there should be nothing special about an OUTLINE_RULE verses a NUM_RULE. So I don't think it is safe to make any changes here, unless you are VERY clear about which points belong together.
Comment 11 Justin L 2021-05-05 12:55:30 UTC
*** Bug 123148 has been marked as a duplicate of this bug. ***
Comment 12 Justin L 2023-05-05 18:51:18 UTC
Please note that the duplicate issue in comment 11 is actually a different use case. However, I expect that a patch for one would solve the other also, but please make sure and test that workflow as well.

repro 7.6+ using the documents and steps in comment 4.