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

Steps to reproduce:

Thunderbird version 68.8.0
Noted Support Forum query on inability to get lists to work as expected.
Support Forum: https://support.mozilla.org/en-US/questions/1286336

Decided to check it out. I'm creating list in compose window and seeing some strange list results that I have not encountered in the past.
I'm not saving anything other than as draft, but I am seeing wrong numbering which is rendering it impossible to create lists when indents are used.

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

Actual results:

I performed a 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
3. letter B is shown, type and press outdent and letter B changes to number 2
4. now a three, so type and press enter
   A. four so type and indent to get A, press enter
5. 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.

Expected results:

List should be numbered 1, 2, A as indent, 3, 4, A as indent, 5.

I created another list and include as image to show what occurred. Image shows both compose screen and view source from saved draft.

Image showing results of simpler list as info in text not clear as indentation not present.

Core bug 1548753?

Problem is that list items < li> lines, are closed using </li> prior to the indent they contain. The </li> should be after the < /ol> - it is not.

Problem still exists in Thunderbird version 78.2.2

Regarding bug 1548753, comment 75
Can someone give an idea of when will this fix will effect TB ?

(In reply to Anje from comment #6)

Problem still exists in Thunderbird version 78.2.2
Regarding bug 1548753, comment 75
Can someone give an idea of when will this fix will effect TB ?

Hey Anje, "someone" sometimes isn't very responsive because his surname is "else", so it'll always be "someone else" ;-)
If you really want answers, use needinfo flag to ask "someone specific" like Wayne (:wsmwk) or myself.

Unfortunately, Bug 1548753 Comment 78 refused to fast-track this in FF for fear of breaking things.

Given that this isn't a new problem, I'd feel better letting this bake longer and ride the 82 train to release.

Per https://wiki.mozilla.org/Release_Management/Calendar (better release calendars are linked inside there),
FF 82 will be released on 2020-10-20, so I believe the next TB 78.x release after that should have the fix. Fingers crossed.

Let's leave this open as a Thunderbird bug to collect duplicates until the fix from bug 1548753 has come to Thunderbird.

FF 82 released and apparently it is still not fixed see bug 1672569

Can we possible prioritise this a little? or Bug 1611861?

@ Anje Is this a duplicate of Bug 1611861?

The editor is limited and problematic in it's own right and being part of the "platform" makes it just a running sore. More than a year after a report of a failure of basic editing no fix is on the horizon. It is very difficult to offer user support when fundamental issues like this take years to address.

There is no point telling users it is a shared component and is the responsibility of firefox to fix. They are simply not interested in politics, only functional software.

Is it time to re-examine the use of the Mozilla editor component at all as it has had so little real love in decades? Perhaps use ckedit as was suggested by MozillaMessaging so long ago. Thunderbird's reputation rests in a large part on the ability to compose email.

Not really an interest area of mine, but more relevant, not something I can impact.

This bug as reported is not reproducible at least on trunk.
There's been many improvements since, and there is ongoing efforts (by Firefox) to improve the editor code. Regarding alternative editors I think there's been a misunderstanding. I don't see how it could help. What you get is another layer of bugs, and in the end the underlying rich editing is still needed (which we are using already).

@ Anje Is this a duplicate of Bug 1611861?

it would appear so.
This problem has had several reports, but only seemed to go wrong when people working on Firefox issue messed up everything and this was messed up code was allowed into Thunderbird.
Plenty of people complaining in the Support forum.

bug 1585047
bug 1598693
bug 1599273
bug 1611861

Left side shows the mess that Thunderbird is currently producing.
Right side is the result after I manually editing the code to correctly close <li> lines - this is the result that Thunderbird should be producing.

I've put the two side by side so it really shows how bad Thunderbird is in the numbering/bulletted list.

Thunderbird appears to be following these rules:
Rule 1: Where no indents the top level numbering is contiguous and correct.
Rule 2: Where only one indent from top level number to top level upper case letter, the number of letters is converted into number equivalent (A,B. C, D, E, F, where G = 7) and that number is shown as next top level number and has no relationship to actual top level numbering.
Hence why a top level 3 can be followed by top level number 7 (see bottom of list in image).
Also Where there is more than one set of indents (2 or more), and outdenting to another indent that is not a top level indent, then same applies.

Rule 3: Where there have been two (or more) indents and now performing the last outdent to return to top level. No matter what the letter, the number of item in list will have a minus one applied.
examples: 3rd in list will be converted to top level number 2. 4th in list will be converted to top Level number 3.

Very strange but true, because the lists are not being closed properly, just simple bad html.

This is an update check using version 91.3.0

As per image, it is now working as expected.