1777183 - TB 102 ignores paragraph setting

Status: RESOLVED MOVED

(Thunderbird :: Message Compose Window, defect, P1)

Description

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

Steps to reproduce:

1. I have HTML Style set to Body Text. This shows correctly in the message compose window under Format / Paragraph.
2. However, when pressing ENTER [in message body], TB creates a new paragraph instead of starting a new line.

Actual results:

Thunderbird is creating a new paragraph.

Expected results:

I should be able to continue typing on the very next line.

Comment 1

[Wayne Mery (:wsmwk)]

I can easily reproduce this with 102.0b8 on Mac

Alice can you find the regression range?

Comment 2

[newsfan]

This is not a bug, it works as designed and has been line this for years. If you compose in paragraph mode, see composition settings, you will always get paragraphs, body text is ignored.

Comment 3

[Nicolai [:Nic]]

(In reply to newsfan from comment #2)

This is not a bug, it works as designed and has been line this for years. If you compose in paragraph mode, see composition settings, you will always get paragraphs, body text is ignored.

I am not in paragraph mode. That's what this is all about.

Comment 4

[newsfan]

Attachment: paragraph setting.png

What do you mean by "not in paragraph mode"? I'm referring to this.

If you uncheck the box, "Body Text" works. If you check the box, you can be in "Body Text" all you like, that will be ignored and paragraphs are added. That's a feature of the M-C editor.

Comment 5

[Nicolai [:Nic]]

I just upgraded to TB 102. The box had always been unchecked and still is unchecked.
Furthermore, in the compose window under Format / Paragraph, the selection "Body Text" is selected when I start typing. Just as it always has been.

I'm still getting a new paragraph when I hit enter, though. That's why I opened this bug report.

Comment 6

[newsfan]

On Windows all works as expected in TB 91 and 102. Are there any add-ons that might interfere?

Comment 7

[Alice0775 White]

Works for me in Daily104.0a1 and Tb102.0 Windows10.

Comment 8

[Nicolai [:Nic]]

Thank you for the hint about the add-ons! I have found the culprit (which claimed to be compatible with TB 102) and just found out that someone already opened an issue on the add-on's repository.

Comment 9

[newsfan]

Please state the add-on name and supply the link to the issue so the next person along doesn't need to re-diagnose the problem.

Comment 10

[Nicolai [:Nic]]

The add-on is "Awesome Emoji Picker" and the issue can be found here:
https://github.com/rugk/awesome-emoji-picker/issues/129

Comment 11

[newsfan]

Thanks, FWIW, I use https://addons.thunderbird.net/en-US/thunderbird/addon/emojiaddin/ which doesn't work in 102 at all, https://github.com/mganss/EmojiAddIn/pull/53.

Comment 12

[Teal Dulcet [:tdulcet] (TB Council)]

I ran mozregression and got this: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=3a43bdbcd359a4de7085b237243fd5b48a8f317e&tochange=be1c2780ec012a2e3c3721c92b7283584667172f, specifically:

Bug 1764652 - Fix hover sate of address book indicator and other CSS improvements in message header. r=henry,Paenglab

However, none of those pushes seem to change the compose window, so the regression must be from mozilla-central.

I have not been able to find a workaround, so I released new versions of the two effected add-ons on ATN yesterday that temporally disable by default the respective autocorrect features that trigger this. The features work fine in Firefox and Chrome, although I am not sure how one would simulate this Thunderbird "Body text" mode in regular ContentEditable elements in a browser.

Comment 13

[newsfan]

Nothing in the regression range points to changes in the compose window editor. What's the corresponding M-C range?

What happens on enter in the compose window is controlled by this code:
https://searchfox.org/comm-central/rev/12d3830dea34b6289efb9dad17496dac8c093ab1/mail/components/compose/content/MsgComposeCommands.js#10465-10476

"defaultparagraphseparator" can be "br", "p" or "div", I think the default is "div" in pure FF. You could experiment with that in FF to see whether you can create the "br" (Body Text) behaviour.

Comment 14

[Teal Dulcet [:tdulcet] (TB Council)]

(In reply to newsfan from comment #13)

You could experiment with that in FF to see whether you can create the "br" (Body Text) behaviour.

Thanks for the information, that is very helpful. We have a test website here: https://rugk.github.io/unicodify/ with the three standard browser input types. I was able to modify that locally to also support these two Thunderbird modes.

However, I am still not able to reproduce this regression in Firefox. In TB 102 with this "Body text" mode enabled, hitting enter adds two line break elements, but in FF 102 with the br separator, I just get the single line break element as expected. For reference, here is the code in our two add-ons that triggers this regression.

Nothing in the regression range points to changes in the compose window editor. What's the corresponding M-C range?

I am not aware of how to get the mozilla-central range from mozregression (when testing TB), but from manually looking up the pushes in that time frame, here is the range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d75eb3fb217f93514703f74785fa7b08281fb279&tochange=e1d1107d438bbdad13a5c4f62911295ac8a16fcf. There are over 150 pushes, but bug 1766355 looks to be the most likely culprit.

Comment 15

[newsfan]

Doesn't mozregression also give an M-C range? Or a way to check which M-C changesets were used to build TB. I don't think your M-C range is large enough, the C-C ones goes from Thu May 19 23:31:54 2022 +0000 to Sat May 21 10:26:59 2022 +0000, that's 1.5 days, the M-C one is from Fri May 20 09:31:26 2022 +0000 to Sat May 21 09:47:23 2022 +0000. The Thu May 19 23:31:54 2022 C-C push was made because M-C changes happened shortly before on Thursday night.

All that said, there were quite a few editor changes in the M-C range, bug 1730442 and bug 1766355. I'd just be interested to know what your add-on does that affects the enter behavior.

Comment 16

[Teal Dulcet [:tdulcet] (TB Council)]

(In reply to newsfan from comment #15)

Doesn't mozregression also give an M-C range? Or a way to check which M-C changesets were used to build TB.

Not that I am aware of, but it would certainly be helpful. Some of the other people CCed to this bug should be able to provide a more definitive answer.

The Thu May 19 23:31:54 2022 C-C push was made because M-C changes happened shortly before on Thursday night.

OK, here is an updated range that goes back to Thu May 19 18:03:18 2022 +0000: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc776278c4ea98788c42b90a53d1c6c37fdf47e7&tochange=e1d1107d438bbdad13a5c4f62911295ac8a16fcf. None of those additional pushes look suspect to me.

I'd just be interested to know what your add-on does that affects the enter behavior.

It is two add-ons, the Awesome Emoji Picker and Unicodify, which have Emoji and Unicode autocorrection features respectively. For example, if the user types :), it would autocorrect it to 😀 (also see bug 1213694). In order to do the autocorrection, it needs to determine the caret position after every key press (it uses a beforeinput event handler). See this post on the Mozilla Discourse for a full explanation of how it works. However, this obviously should have no effect on the enter behavior when no autocorrections are performed.