Closed Bug 1777183 Opened 2 months ago Closed 2 months ago

TB 102 ignores paragraph setting

Categories

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

Thunderbird 102
Unspecified
All

Tracking

(thunderbird_esr102+ affected)

RESOLVED MOVED
Tracking Status
thunderbird_esr102 + affected

People

(Reporter: Nic, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, regressionwindow-wanted)

Attachments

(1 file)

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.

I can easily reproduce this with 102.0b8 on Mac

Alice can you find the regression range?

Blocks: tb102found
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(alice0775)
OS: Unspecified → All
Priority: -- → P1

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.

(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.

Attached image 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.

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.

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

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

Flags: needinfo?(alice0775)

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.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → MOVED

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.

Flags: needinfo?(bugzilla)

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

Flags: needinfo?(bugzilla)

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.

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.

(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.

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.

(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.

You need to log in before you can comment on or make changes to this bug.