Bug 150748 - Indentation when creating a list fails on c) and d)
Summary: Indentation when creating a list fails on c) and d)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Bullet-Number-Outline-Lists
  Show dependency tree / graph
 
Reported: 2022-09-02 02:40 UTC by Real Ice Cube
Modified: 2025-07-30 08:31 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
icons for working with lists - unreliable (2.64 KB, image/png)
2023-07-30 17:00 UTC, dantegd 		Details
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 Real Ice Cube 2022-09-02 02:40:01 UTC 
Description:
When creating a list that is indented (with TAB), items c and d will always lose their indent.  Tried on multiple computers running Windows on new and several older versions of Writer.  List ends up looking like below:
   a)
   b)
c)
d)
   e)
   f)

Steps to Reproduce:
1. Type "a." or "a)" with text after it.
2. Repeat for "b." / "b)" and so on
3. When you get to "c." or "c)", the indent will be lost.  Also happens for "d." / "d)"
4. Indent returns for "e." / "e)" and following letters.
5.  Problem will not occur unless text is following the items on the list (not just a, b, c, etc.)

Actual Results:
	a) first item, retains indent when I press “enter”
	b) second item, retains indent when I press “enter”
c) third item, LOSES indent when I press “enter”
d) fourth item, LOSES indent when I press “enter”
	e) fifth item, retains indent when I press “enter”
	f) so do the rest

Expected Results:
	a) first item
	b) second item
	c) third item
	d) fourth item
	e) fifth item
	f) etc.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
See above
Comment 1 Mike Kaganski 2022-09-02 06:28:04 UTC 
Repro using Version: 7.4.1.1 (x64) / LibreOffice Community
Build ID: 0a046a10cbf1679eea5538bd3ab63156caa3a036
CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (ru_RU); UI: en-US
Calc: CL Jumbo.

If you enable "Bulleted and numbered lists" under AutoCorrect Options (Options tab), it would change a bit: for a and b, it would work the same, but for c, it turns the line into a *numbered list*, using *roman numerals* (so after pressing Enter, the next line is automatically numbered "ci").

Disabling "Delete spaces and tabs at end and start of line" has no effect on this.
But disabling autocorrect while typing as a whole fixes this.

Using OOo 3.2.0, the picture is the same.

It looks that the problem is somehow related to the automatic recognition of Roman numerals. It works erratically, though: it should not affect the text when the "Bulleted and numbered lists" is disabled (the default now).
Comment 2 Mike Kaganski 2022-09-02 06:37:44 UTC 
By the way, the same problem happens when you type "<tab>1. blah", which confirms the list detection theory.
Comment 3 Mike Kaganski 2022-09-02 06:56:17 UTC 
(In reply to Mike Kaganski from comment #1)
> Disabling "Delete spaces and tabs at end and start of line" has no effect on
> this.

But disabling "Delete spaces and tabs at beginning and end of paragraph" avoids the problem.
So it looks like the "Delete spaces and tabs at beginning and end of paragraph" only works in conjunction with other matching rules (even disabled, like numbering) - so looks like a bug in "Delete spaces and tabs at beginning and end of paragraph". It likely should work regardless of the other matching rules.
Comment 4 Mike Kaganski 2022-09-02 07:01:34 UTC 
A possible code pointer: SwAutoFormat::DeleteLeadingTrailingBlanks in sw/source/core/edit/autofmt.cxx.
Comment 5 dantegd 2023-07-30 16:42:17 UTC Comment hidden (off-topic)
Comment 6 dantegd 2023-07-30 17:00:16 UTC Comment hidden (off-topic)
Comment 7 dantegd 2023-07-30 17:06:37 UTC Comment hidden (off-topic)
Comment 8 QA Administrators 2025-07-30 03:10:33 UTC Comment hidden (obsolete, spam)
Comment 9 Takenori Yasuda 2025-07-30 08:31:11 UTC 
This bug seems similar to Bug 166539 and Bug 67797—could it be a duplicate?
What do you think?