(This is a bug report about the calendar software in thunderbird 91.8.0)

Problem A: Every other newline press is ignored

When trying to insert a newline into a task description, you actually have to press the Enter key twice.

Actions:

1. Insert some test into task description
2. At end of line, Press Enter => new line is created => good
3. Press Enter again => nothing happens => bad
4. Press Enter yet again => another new line is appended => good.

This makes keyboard feel "sluggish", and is distracting for fast typers.

Problem B: Inserting newlines at top of screen has those new lines scroll of screen

Actions:

1. Insert enough lines of text into task description so that it extends to bottom of visible window
2. Go to top of window.
3. Press Enter => nothing happens
4. Press Enter again => nothing obvious happens. But on closer inspection it actually did insert a new-line, but scrolled it off the top immediately.

This behavior is rather jarring, can't we get the behavior from 78.14 back where it scrolled the text down, and visibly showed the new line?

Thanks Alain, confirming as described on 91.8.1 (64-bit) and 102.0a1 (2022-05-03) (64-bit), Win10.
Works in 78.14.0 (32-bit), Win10, but we only had plaintext for task descriptions there, now it's HTML editor. Probably regressed by that change.
Alice, would you have a regression window?

For users who want to create spacing ("empty lines") in their task descriptions, this must be pretty annoying.
Workaround: Use Shift+Enter to insert empty lines correctly.

Most likely, what happens is that internally, Enter creates a new paragraph <p></p>, whereas Shift+Enter creates line break </br>. Not sure why it wouldn't allow creating empty paragraphs, same scenario works in our composition editor. If plain Enter creates paragraphs, they should also look like paragraphs and create vertical spacing around themselves.

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=e7026840b04d83bc692eca4dac9cc9cd69f84bff&tochange=87d34cfcf232608bc8046c8b1cfbfd78d13066eb
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=152fdda295bb5f6658d65c2bc48bc6aae499b526&tochange=1f6c9c348681b03a8af47fe6bd51a52cf00c89e5

I bet that's the <br> vs. <p> funnyness in the editor. IIRC there's a setting how we can alter the newline behavior of the editor. (We used to have a pref for the email editor.)

Workaround: Use Shift+Enter to insert empty lines correctly.

Thanks. Shift-Enter does indeed solve problem A, but not problem B (inserting newline at top of currently visible window)

And besides, its cumbersome to have to remember to press shift along with enter where enter alone used to work perfectly fine.

(We used to have a pref for the email editor.)

YES. That's the way to go. If there are indeed people who do like the new behavior (why?), just make a pref, so we get to chose.

Please file one bug report per issue. "Problem B" behaves as expected for me. Of course, if you fill the window with empty lines, it's going to be hard to know where you are. I assume that you're going to look at the scrollbar, and it correctly represends the state of the editor, in my testing. I was testing with Shift-Enter.

If there are indeed people who do like the new behavior

The current newline behavior makes no sense to me, indeed. Either

• ENTER always just inserts a line break <br>, continuing on the directly following line, or
• ENTER inserts a paragraph <p>, and inserts a linebreak plus some vertical whitespace between paragraphs.
  It's arguable which of these two are correct, and I'd claim that neither options would be a bug.

But it seems that ENTER, when at the start of a line, sometimes has no visible effect. That makes no sense to me, and we should fix that.

I wonder whether the editor inserts a <br> on the first ENTER, then on the second connsecutive ENTER replaces the <br> with a <p>. But maybe the default CSS styling of <p> is not correct and renders it without vertical space, making it appear the same as <br>, therefore showing no visual effect when the <br> changes to <p>. If I'm right, it's just a matter of including the right default CSS stylesheet.

I see the same behavior in calendar appointment descriptions.

(In reply to Ben Bucksch (:BenB) from comment #3)

IIRC there's a setting how we can alter the newline behavior of the editor. (We used to have a pref for the email editor.)

[Missed this the first time around]. Great to hear this! If you remember the name of the setting, please tell me.

(In reply to Alice0775 White from comment #2)

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=e7026840b04d83bc692eca4dac9cc9cd69f84bff&tochange=87d34cfcf232608bc8046c8b1cfbfd78d13066eb

Thank you very much Alice for fast regression range!

(In reply to Thomas D. (:thomas8) from comment #1)

Works in 78.14.0 (32-bit), Win10, but we only had plaintext for task descriptions there, now it's HTML editor. Probably regressed by that change.

As I suspected: regressed by bug 1607834. Let's ask Neil.

Most likely, what happens is that internally, Enter creates a new paragraph <p></p>, whereas Shift+Enter creates line break </br>. Not sure why it wouldn't allow creating empty paragraphs, same scenario works in our composition editor. If plain Enter creates paragraphs, they should also look like paragraphs and create vertical spacing around themselves.

Neil, do you know more about the current behaviour in event descriptions wrt <p> vs. <br>? Something is wrong here.

(In reply to Ben Bucksch (:BenB) from comment #6)

Thank you Ben for your thoughts!

The current newline behavior makes no sense to me, indeed. Either

• ENTER always just inserts a line break <br>, continuing on the directly following line, or
• ENTER inserts a paragraph <p>, and inserts a linebreak plus some vertical whitespace between paragraphs.

For intra-app ux-consistency with our composition editor, imo maybe defaulting to <p> and applying correct CSS for that would be preferable. It's convenient and produces nice formatting with less effort. Typically when we try to add an "empty line", what we're really after is "some vertical spacing", and that's available with less keystrokes when using <p>. I can testify that the temptation to use <br> to start a new sentence on a new line without vertical spacing is big, but more often than not it doesn't make for logically well-structured text. Modern word processors have also gone through the same change (inter-app ux-consistency). Perhaps we could even hook it up with the composition pref, any user would likely want the same behavior consistently.

But it seems that ENTER, when at the start of a line, sometimes has no visible effect. That makes no sense to me, and we should fix that.

Yes, that's this bug ;-)

I wonder whether the editor inserts a <br> on the first ENTER, then on the second connsecutive ENTER replaces the <br> with a <p>. But maybe the default CSS styling of <p> is not correct and renders it without vertical space, making it appear the same as <br>, therefore showing no visual effect when the <br> changes to <p>. If I'm right, it's just a matter of including the right default CSS stylesheet.

Quite possible.

I see the same behavior in calendar appointment descriptions.

Good observation, thanks. Adjusting summary.

(In reply to Alain Knaff from comment #7)

(In reply to Ben Bucksch (:BenB) from comment #3)

IIRC there's a setting how we can alter the newline behavior of the editor. (We used to have a pref for the email editor.)

[Missed this the first time around]. Great to hear this! If you remember the name of the setting, please tell me.

For composition window, the pref to choose between <p> and <br> default behaviour is
mail.compose.default_to_paragraph (true/false)

(In reply to Thomas D. (:thomas8) from comment #9)

For composition window, the pref to choose between <p> and <br> default behaviour is
mail.compose.default_to_paragraph (true/false)

Thanks, but unfortunately this doesn't change anything. Variable was true by default, if I change it to false, the behavior still happens :-(

(In reply to Ben Bucksch (:BenB) from comment #6)

I wonder whether the editor inserts a <br> on the first ENTER, then on the second connsecutive ENTER replaces the <br> with a <p>. But maybe the default CSS styling of <p> is not correct and renders it without vertical space, making it appear the same as <br>, therefore showing no visual effect when the <br> changes to <p>. If I'm right, it's just a matter of including the right default CSS stylesheet.

Richard - would you know how to "include the right default CSS stylesheet"?

This doesn't happen in the normal composer text field and the only difference is the added messageQuotes.css.

When I check the newly opened task field in Inspector I see when it is empty only a
<br _moz-dirty="">
and when I press ENTER I see

<div _moz-dirty="">
  <br _moz-dirty="">
  <br _moz-dirty="">
</div>

pressing again ENTER changes to

<div _moz-dirty="">
  <br _moz-dirty="">
</div>
<div _moz-dirty="">
  <br _moz-dirty="">
</div>

So the second ENTER adds a second BR to the div and the next ENTER splits the two BR into two DIVs.

Maybe Masyuki San knows what happens here and needs to be fixed.

Yeah, it's odd behavior... At the second step, first, editor consider to insert a line break.
https://searchfox.org/mozilla-central/rev/4719c903af605c2caeda3bb1ce4edb9ca58bf68e/editor/libeditor/HTMLEditSubActionHandler.cpp#1688,1690
Then, it inserts a <br> element here.
https://searchfox.org/mozilla-central/rev/4719c903af605c2caeda3bb1ce4edb9ca58bf68e/editor/libeditor/HTMLEditSubActionHandler.cpp#1739
Finally, it does nothing in Firefox.
https://searchfox.org/mozilla-central/rev/4719c903af605c2caeda3bb1ce4edb9ca58bf68e/editor/libeditor/HTMLEditSubActionHandler.cpp#1749

So, in the case, looks like that it runs different path. Is the editor is in designMode (e.g., using xul <editor>)?

I don't know enough to say in which mode it is. Here are the calls: https://searchfox.org/comm-central/search?q=let%20editorElement%20%3D&case=false&regexp=false&path=. Maybe Ben can help.

<br> ?
<div _moz-dirty="">?

Why is it getting lost in there at all? Maybe that should be the question that needs addressing? And if this is somehow wanted (to lure in outlook users, or whatever?), can't we have a (discoverable) config switch that reverts back to the old simple (and stable) behavior?

Unfortunately, mail.compose.default_to_paragraph does nothing :-(

Still an issue in 91.13.0

From my individual user perspective:
I agree that it should be possible to go back to the old simple behavior without HTML. In these note fields, simplicity is important.

Similar to this issue, I found that the OpenTasks/DAVx5 setup on my Android also shows sporadic inconsistencies due to the ALTREP parameter (couldn't make it reproducable yet). Maybe this happens with other apps as well. Although this is an issue of the apps, Thunderbird should pragmatically allow to go back to plaintext-only.