User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

1. On a blank email, create a numbered list with the toolbar button
2. Add some entries to this list
3. Indent some of these entries
4. Save the resulting email as an HTML file (File > Save As > File)

Actual results:

The resulting HTML contains <ol> elements directly within the top-level <ol> - see the example below. Note that this causes issues in the display of the <li> numbers as reported in bug #1548753.

<ol>
<li>Top level entry one<br>
</li>
<ol>
<li>Indented entry one</li>
<li>Indented entry two<br>
</li>
</ol>
<li>Top level entry two<br>
</li>
<ol>
<li>Indented entry one<br>
</li>
</ol>
</ol>

Expected results:

All nested <ol> elements should be contained within an <li> element, as below.

<ol>
<li>Top level entry one<br>
<ol>
<li>Indented entry one</li>
<li>Indented entry two<br>
</li>
</ol>
</li>
<li>Top level entry two<br>
<ol>
<li>Indented entry one<br>
</li>
</ol>
</li>
</ol>

In what way is this not a duplicate of bug 1548753?

bug 1548753 is to do with the display of a list structured like this, while this bug is about the creation of lists in the email compose window. It is not a duplicate, as even if bug 1548753 is resolved this behaviour may still be present and have an impact when the composed email is viewed with another client.

Using TB version 68.8.0
I saw a Support Forum query on inability to get lists to work as expected and decided to check it out. I'm creating list in compose window and seeing some strange list results that I have encountered in the past.
I'm not saving anything other than as draft, but I am seeing wrong numbering.

I enclose image showing what I see in the 'Write' window and also showing 'View Source of saved as draft.

odd numbering occuring in list

I performed a more simple list:
1. type one and select numbered list and press enter
2. number tow is shown, type and press enter
A. number three is shown, type and press indent, changes to A, press enter
2. letter B is shown, type and press outdent and letter B changes to number 2
3. now a three, so type and press enter
A. four so type and indent to get A, press enter
2. get a B now outdent and number two is there again

Source shows:
<ol>
<li>type one and select numbered list and press enter</li>
<li>number tow is shown, type and press enter</li>
<ol>
<li>number three is shown, type and press indent, changes to A,
press enter</li>
</ol>
<li>letter B is shown, type and press outdent and letter B
changes to number 2<br>
</li>
<li>now a three, so type and press enter<br>
</li>
<ol>
<li>four so type and indent to get A, press enter<br>
</li>
</ol>
<li>get a B now outdent and number two is there again<br>
</li>
</ol>

What is really odd, the <br> shown in <li> as there was definately no break, no space, double checked, there is nothing after the cursor which is immediately after the last letter/number. It seems pressing Enter/Return key is suddenly adding a break.

Is this the same bug or do you think this should be reported as different ?

Support Forum: https://support.mozilla.org/en-US/questions/1286336
Basically creating lists has gone awol in 68.8.0

I'm seeing this using 78.3.0 on Ubuntu Linux. Also present in the 68.10.0 from Ubuntu.

When composing the same list in SeaMonkey 2.53.4 the 6 becomes a 3 as expected.

Source code is:

<ol>
<li>Top</li>
<li>Level</li>
<ol>
<li>and</li>
<li>several</li>
<li>second</li>
<li>level</li>
<li>things</li>
</ol>
<li>item</li>
</ol>

TB 78.5.0
More evidence, if it needed.

Started with a new blank HTML email
Added some text and then created a numbered list
Indented the third item

Attached image shows before and after indenting

I examined the HTML, and it appears that the issue is quite simple. When indenting an item, it creates a new ul or ol but does not place that list inside the prior list item, which is now the parent. Moving the </li> from the new parent to the end of the embedded ol or ul corrects the numbering.

I can't reproduce on trunk. Walt's example from comment 7 works as it should there (the 6 becomes a 3 as expected)

Just to confirm version 91.3.0 is working as expected.