209090 - Hitting enter in numbered list in quoted mail causes numbering to change (mail editing only)

Status: NEW

(Core :: DOM: Editor, defect, P4)

Description

[Brendan Eich [:brendan]]

Joe said to file this on editor:core.  It's a special case that mail compose
should enable.

/be

Comment 1

[Kai Engert (:KaiE:)]

Updating summary to be easier to understand.

To reproduce, do this:

- compose a new mail message
- click the numbered list icon
- enter a, hit enter, enter b, hit enter twice

you'll now see
  1. a
  2. b

- send the message
- receive the message, you still see the correct original text
- place the caret after "a"
- hit enter

Actual behaviour:
  The text "2. b" changes into "1. b"

Expected behaviour:
  No text should change.

Comment 2

[Kai Engert (:KaiE:)]

I don't see this behaviour when editing the same content in non-mail editing
mode. This is because we don't split the quoting in non-mail editing mode.

The splitting probably causes us to have two separate lists. Each list gets
rendered separately by layout.

I suppose we need to change the "split numbered list" code to somehow explicitly
tell all list items what number they should use, and that should remain fixed
for any further future edit actions.

Nominating topembed, since this feature might be used in mail applications
embedding Gecko.

Comment 3

[Joe Francis]

kaie: note that we only want this explicit numbering in the mailcite case.  In
normal editing, if you split a list, we want the current bahavior (renumbered
from 1).

Comment 4

[Kevin McCluskey (gone)]

editorbase+

-> Daniel, can you look at this one?

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I told brendan "I am working on it". I am.

Comment 6

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Ok, let's have the following list and let's assume it's in a quoted HTML mail:
<blockquote type="cite">
  <ol>
    <li>aaaaa</li>
    <ol>
      <li>bbbbb</li>
      <li>ccccc</li>
      <li>ddddd</li>
      <ol>
        <li>eeeee</li>
        <li>fffff</li>
        <li>ggggg</li>
      </ol>
      <li>hhhhh</li>
      <ol>
        <li>iiiii</li>
      </ol>
    </ol>
    <li>jjjjj</li>
    <li>kkkkk</li>
  </ol>
</blockquote>

Let's place the caret after fffff and press return, we should end up with

<blockquote type="cite">
  <ol>
    <li>aaaaa</li>
    <ol>
      <li>bbbbb</li>
      <li>ccccc</li>
      <li>ddddd</li>
      <ol>
        <li>eeeee</li>
        <li>fffff</li>
      </ol>
    </ol>
  </ol>
</blockquote>
<br>
<blockquote type="cite">
  <ol start="2">
    <ol start="4">
      <ol start="3">
        <li>dddddf</li>
      </ol>
      <li>dfgdfdfgdfg</li>
      <ol>
        <li>dfgdfgdfg</li>
      </ol>
    </ol>
    <li>dfgdfgdfgdfg</li>
    <li>dfgdfgdfgdfg<br>
    </li>
  </ol>
</blockquote>

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: fix #1... hmmm, I like it :-)

Comment 8

[Kathleen :Brade]

Comment on attachment 126114 [details] [diff] [review]
fix #1... hmmm, I like it :-)

in GetListItemIndex, move startAttr down to where it is first used:
+  NS_NAMED_LITERAL_STRING(startAttr, "start");

r=brade

Comment 9

[Mike Cowperthwaite]

*** Bug 252172 has been marked as a duplicate of this bug. ***

Comment 10

[Mike Cowperthwaite]

Daniel, you put a patch up that's gotten its review -- can you spare the time to 
push it thru to completion?

Comment 12

[Miguel]

Dear team.
There is a working patch waiting to be pushed into production for 15 (!) that resolves a pretty basic problem in the Editor.

Can someone kindly make an effort to push this into production?

Comment 13

[Makoto Kato [:m_kato]]

(In reply to Miguel from comment #12)

Dear team.
There is a working patch waiting to be pushed into production for 15 (!) that resolves a pretty basic problem in the Editor.

Can someone kindly make an effort to push this into production?

This is too old, so we cannot apply/approlve this. And I don't know that this still occurs. When I create test case via comment #6 with contenteditable, I cannot reproduce this. Does anyone have test case?

Comment 14

[waynemcl]

Hi all
I'm on Thunderbird 78.3.1 (32-bit), on Windows 10 (64-bit), build 19041.508, and this is still happening for me, per comment #6. (Both when relying to emails from others, and an email to self like the example.) Thanks.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This is still reproducible. I think that for solving this bug, we need to add some hack around here.

Comment 17

[John Pye]

I can confirm that this bug is still present as of Thunderbird 102.3.3, and it's a super annoying one for people who like and heavily use Thunderbird's nice quoting system for in-line comment responses to emails, in particular with HTML emails.

My suggestion would be to apply some XLST-style filters to HTML text while it is being "quoted" (having the sidebar added). The change should be for all list items <li> within ordered lists <ol> to have the value field set. This way, broken lists would retain their numbering.

<p>Apollo astronauts:</p>
<ol>
<li value=1>Neil Armstrong</li>
<li value=2>Alan Bean</li>
<li value=3>Peter Conrad</li>
</ol>
my comment about that stuff
<ol>
<li value=4>Edgar Mitchell</li>
<li value=5>Alan Shepard</li>
</ol>

Alternatively, since I guess that new </ol> and <ol> tags are being added when a list is broken by message editing within quoted text, the change could be made that time of breaking the list. I am not sure which would be easier from an implementation point of view. In that case, the <ol start=xx> attribute could be used instead:

<ol>
<li>Mix flour, baking powder, sugar, and salt.</li>
<li>In another bowl, mix eggs, milk, and oil.</li>
</ol>
my comment about that
<ol start=3>
<li>Stir both mixtures together.</li>
<li>Fill muffin tray 3/4 full.</li>
<li>Bake for 20 minutes.</li>
</ol>

Comment 18

[John Pye]

Confirming that this bug is still here in Thunderbird 102.13.0 on Ubuntu 20.04.6.

Can we please tag this bug in some way for attention? It's a really bad look and there is a TWENTY YEAR OLD PATCH there which I sure at least contains some useful logic.

I thought I would also note that I found this code fragment, which might lead to some kind of alternative strategy, potentially.
https://codepen.io/NUTTYCHEESECAKEKOALA/pen/BayNpYv

Comment 19

[John Pye]

Attachment: fixlist.py

I made a hacky workaround for this bug, which attempts to transform the HTML of the message to make it robust against Thunderbird poor logic for breaking quoted HTML elements like <ol>. It also attempts to clean up some Word and Outlook derived HTML and quasi-HTML markup.

I haven't figured out how to build Thunderbird, so the patch above isn't something I've been able to look at. Perhaps bits of the above and bits of the earlier patch can be cobbled together by someone who knows more.

Comment 20

[John Pye]

PS that script is limited to Linux at the momen.t It depends on Gtk3 for reading HTML from the clipboard, and the command-line xclip for writing HTML back to the clipboard. Other code would be needed to support other platforms, including non-Gtk linux versions.

Comment 21

[chrizilla]

(In reply to John Pye from comment #18)

I found this code fragment, which might lead to some kind of alternative strategy, potentially.
https://codepen.io/NUTTYCHEESECAKEKOALA/pen/BayNpYv

By "alternative strategy" you mean li::before ? AFAIK this doesn't correctly align single/double digit ordinal numbers (see example in your link), depends on the recipient client's ability to render CSS (which isn't always the case) and probably has other downsides, too.
<ol start="4"> or <li value="4"> (used by your script) is a much simpler solution and also alters the original HTML code less. Win-win, no ?

(In reply to John Pye from comment #19)

Created attachment 9346418 [details]
fixlist.py

I made a hacky workaround for this bug, which attempts to transform the HTML of the message to make it robust against […] breaking quoted HTML elements like <ol>. It also attempts to clean up some Word and Outlook derived HTML and quasi-HTML markup:

- applies <li value=X> attributes to all list items within <ol>, such that, when
  editing the email, a broken quoted section will preserve the original list numbering

- reformats <p class="MsoListFormat"> to indented paragraphs with approximately
  the correct indenting, minus the heavy Microsoft-specific HTML markup.

- strips out all Microsoft Outlook markup like <o:p> </o:p>

- strips out pointless <span style="mso-fareast-language:EN-US"> markup.

Thank you for your work! Your additional clean-up functions seem very useful.