Bug 143784 - Numbered list misbehaves with custom numbering - numbers disappear. Writer, Editing, Formatting.
Summary: Numbered list misbehaves with custom numbering - numbers disappear. Writer, E...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.0.2 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-09 10:33 UTC by al F
Modified: 2021-08-10 10:28 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description al F 2021-08-09 10:33:59 UTC
Description:
Numbering misbehaves when creating a numbered list that needs to start with customized text (in my case I need the format YY/NNN where YY is static while NNN changes - like 21/116, 21/117, etc).

Opening the dialog "Bullets and numbering > Customize" I choose a starting number like "120" and enter "21/" in the field "Before".

The dialog preview shows the correct formatting (21/120), however on clicking OK the actual list items display as "21/" - the numbering missing.

If I then return to the dialog "Bullets and numbering > Customize" to remove the text in the "Before" field, the result is a list completely without numbering.

Steps to Reproduce:
1. Create numbered list in text body paragraph
2. Open dialog "Bullets and numbering > Customize"
3. Set "Start at" to "120" and "Before" to "21/" ("Start at" does not need editing to reproduce)
4. Click OK.

Actual Results:
The numbered list displays like this:
21/ <List item 1>
21/ <List item 2>
21/ <List item 3>

Expected Results:
21/120 <List item 1>
21/121 <List item 2>
21/122 <List item 3>


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.2.0.2 / LibreOffice Community
Build ID: 614be4f5c67816389257027dc5e56c801a547089
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: nb-NO (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 1 al F 2021-08-09 10:43:17 UTC
The same unwanted behaviour applies to the dialog "Tools > Chapter Numbering" and trying to set the desired format for headings.
Comment 2 al F 2021-08-09 10:51:44 UTC
(In reply to al F from comment #1)
> The same unwanted behaviour applies to the dialog "Tools > Chapter
> Numbering" and trying to set the desired format for headings.

Sorry, typo here. This should read:

The same unwanted behaviour DOES NOT apply to the dialog "Tools > Chapter Numbering" and trying to set the desired format for headings.
Comment 3 Jean-Baptiste Faure 2021-08-09 16:56:29 UTC
Not reproducible for me with 

Version: 7.2.1.0.0+ / LibreOffice Community
Build ID: 6b393b6cc65992ba6af4476024bb2f26518c388b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Ubuntu_20.04_x86-64
Calc: threaded

Please, could you try vcl plugin gtk3 to test if the issue comes from the kf5 plugin?

Status has been set to NEEDINFO, please set it back to UNCONFIRMED once requested information has been provided.

Best regards. JBF
Comment 4 al F 2021-08-09 17:19:47 UTC
Well, when trying to create a list from scratch with all of these:

SAL_USE_VCLPLUGIN=gtk3/gen/kf5 swriter

I can't reproduce the unwanted behaviour, not even in the original document. Seems like there was a ghost somewhere else in my system.

Thanks. I forgot it's always a good idea to reboot before jumping to conclusions...
Comment 5 Jean-Baptiste Faure 2021-08-09 20:45:49 UTC
(In reply to al F from comment #4)
> Well, when trying to create a list from scratch with all of these:
> 
> SAL_USE_VCLPLUGIN=gtk3/gen/kf5 swriter
> 
> I can't reproduce the unwanted behaviour, not even in the original document.
> Seems like there was a ghost somewhere else in my system.
> 
> Thanks. I forgot it's always a good idea to reboot before jumping to
> conclusions...

Thank you for your answer. Closing as WorksForMe. Please feel free to reopen if the problem comes back.

Best regards. JBF
Comment 6 Timur 2021-08-10 10:28:17 UTC
https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status

WFM is when there was a confirmed bug but not anymore, indicating fix that can be found with reverse bibisect. 

Here it's INsufficientData, indicating possible but undefined problem, helpful for eventual similar report.