User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.75 Safari/537.36

Steps to reproduce:

Toggled "ordered list" on
wrote first line, got number 1
wrote second line, got number 2
wrote third line, got number 3
typed TAB, got indent
wrote another line, got number 1 with indent (OK)
typed Shift-TAB, got ident back to base
wrote another line...

Actual results:

got number 2

Expected results:

get number 4

I can confirm the issue. This worked correctly in TB 60.

Alice, another regression :-(

I can reproduce the issue on Firefox69.0.1, Nightly71.0a1, but not on 60.9.0ESR.

Steps to Reproduce:

1. Open https://www-archive.mozilla.org/editor/midasdemo/
2. Click on the editor
3. Click Ordered List icon
4. Type something and hit Enter, repeat several times
5. Click Indent icon
6. Type something and hit Enter
7. Click Outdent icon
8. Type something and hit Enter

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5dc0652cd024fef30217ac3e6087b7a32f16967f&tochange=9bad25ccc8d0414e21d3c8d4dcf2178a97bb07c3

I looked at Midas, but shift tab didn't work there. Great you figured it out.

This is basically bug 1548753 / bug 525888.

Thunderbird Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=3689c93f5445414ce54deb911842323e24fd0a1e&tochange=bca07912f1dd450719ea332823565918e87e4b6f
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4a692c812a3fe2f893d2a6e25b9490b38415c907&tochange=3d5cd10cb1b20c1f83a189fbeb2e22f470bac0ec

Confirmed same regression.

Well, that worked in mozilla60, so it cannot me a dupe of the ancient bug 525888. So let's move it to bug 1548753. Any chance of fixing that? We're going to have many TB users complaining about this regression :-(

Actually, bug 1548753 comment #0 complains about changes to behaviour in exactly the same regression range in FF 68 as the one in comment #2.

Any chance of fixing that?

We're following the spec so it's not a bug. The problem is that the HTML markup is invalid (OL can't have direct OL children). The underlying bug for that issue is bug 525888, which is a bug we should fix. I'll take a look at that...

Thanks for the comment, Mats. As I said in bug 1548753 comment #33, IE, Edge and Chrome (and FF before 68) display the invalid HTML in a way one would expect. In any case, the <li> preceding and following the invalid injected direct <ol> child shouldn't have the same number, as wrong as the markup may be. Does the spec specify the counting scheme in case of invalid markup and all other browsers infringe the spec?

Does the spec specify the counting scheme in case of invalid markup and all other browsers infringe the spec?

Yes, the authoritative spec is CSS Lists which defines the built-in list-item counter which is used for HTML list elements. The CSS spec doesn't care about what is valid HTML or not, it only cares about the flattened DOM tree and where a CSS counter originates. See https://drafts.csswg.org/css-lists-3/#creating-counters for details. This is nice because the list-item counter behaves exactly as any other CSS counter that the author specifies. Unfortunately, it's not compatible with how the legacy list item numbering worked for invalid HTML markup. I'm guessing the spec authors prioritized compat with other CSS counters over compat with invalid HTML markup. (I wasn't involved in the CSS Lists spec when that decision was made so I don't know the reasoning.) It seems reasonable though since otherwise an UA would have to have two separate, slightly incompatible, numbering schemes for list counters just to support invalid HTML markup. (It's compatible for valid HTML markup as far as I know.)

So I think the solution is to fix execCommand("indent") so that it doesn't generate invalid HTML markup. (Which seems like a good thing to do in general, not just to fix the numbering.)

FWIW, I provided a WIP patch for that in bug 525888, but it seems to have bit-rotted since then...