1281664 - convert email body from Paragraph to Body Text - can't insert characters in correct place

Status: RESOLVED FIXED

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

Description

[Graham Menhennitt]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Thunderbird 45.1.1 on both Windows and FreeBSD (and several previous versions)

- compose a new email
- email body format defaults to Paragraph format
- enter some text into the email body with multiple single line paragraphs by hitting Enter twice between each paragraph (note: must hit Enter twice)
- select all the text in the email body
- convert the text to Body Text by selecting that option in the combo box
- using the mouse, place the cursor inside the middle of a line of the body text
- enter some new text


Actual results:

new text is entered on the empty line before the cursor


Expected results:

new text should appear at location of cursor

Comment 1

[Graham Menhennitt]

If the empty line is deleted and then re-added, text can be entered into the correct place.

Comment 2

[Jorg K (CEST = GMT+2)]

This would be a Mozilla Core editor bug. However, I cannot reproduce it with your instructions.

In paragraph more I typed:
aa aa aa<enter><enter>bb bb bb<enter><enter>cc cc cc<enter><enter>dd dd dd

I selected the whole lot and selected "Body Text". Now where do I place the caret to start typing?

Please attach a screenshot or save the message as a draft at that stage and attach it to the bug. Or use the add-on ThunderHTMLedit to inspect the HTML and paste that here together with an indication of where to place the cursor.

BTW, we had a bug that sounding similar (bug 1272058), but that's fixed in 45.1.1.

Comment 3

[Graham Menhennitt]

Attachment: snapshot1.png

in paragraph mode - all text selected

Comment 4

[Graham Menhennitt]

Attachment: snapshot2.png

convert to Body Text

Comment 5

[Graham Menhennitt]

Attachment: snapshot3.png

place cursor in "cc" line

Comment 6

[Graham Menhennitt]

Attachment: snapshot4.png

press 'e' - character appears on empty line above cursor

Comment 7

[Graham Menhennitt]

I've uploaded four screenshots. Unfortunately, the caret is not captured. It was placed in the middle of the "cc" line when I types "e". The problem seems to happen when the caret is on any line except the first.

It does sound very much like bug 1272058, but I'm definitely running 45.1.1. It happens on both Windows and FreeBSD under KDE.

Comment 8

[Jorg K (CEST = GMT+2)]

Thanks, I can reproduce it now. For the record: I was using "fixed width" for my composition and then the system behaves differently.

This is a Mozilla core editor bug with very little chance to get it fixed.

Looks like a regression from bug 1250010, maybe. There was one already: bug 1263883.

Comment 9

[Graham Menhennitt]

Ok, thanks for looking at it.

Just for completeness, I tried it with a new Thunderbird profile - it happens there too.

Comment 10

[Dan Pernokis]

I think some of these cursor position problems depend on phase of the moon.  I've had ENTER key cause a proper paragraph as expected, then next time (with no change in typing) just a line feed.  Also had ENTER cause a paragraph, only to be followed by an extra linefeed at the moment I start typing the newly created  line.  Backspace-erasing to the previous line may or may not result in the next ENTER key working properly, sometimes giving proper paragraph and sometimes only linefeed.  (I think the write mode toggles itself between "Paragraph" and "Body Text" for no obvious reason.)

I find this new format to be totally frustrating, mostly because of its unpredictability.  Ideally, the problems should be fixed, but IMO if consistency can be gained (even if incorrect for now), that would be a plus.

Running TB 45.1.1 Release on Windows 7/32 Pro (SP1).  Write mode is typically "Paragraph" (with Calibri font).

Comment 11

[Jorg K (CEST = GMT+2)]

I've been using the new default "Paragraph" format for a while now. It works quite well, but sadly it has exposed a few bugs in the Mozilla core editor which we use to compose e-mail.

We keep track of problems we find and fix in this meta bug 1248971. The bug you mention "Backspace-erasing to the previous line ..." is bug 1265800. It quite annoys me as well. The bug is assigned to Aryeh and there is a good chance that he will fix it when he returns to work in August 2016.

Comment 12

[Dan Pernokis]

Thanks, Jorg -- I'm cc'd on the meta.

My bug 1267098 was flagged there as a duplicate, but please don't overlook it.  Turns out there are several distinct malfunctions documented there as you yourself pointed out (sorry, at the time I thought it was one bug) -- and these are still current.  And again the common thread is unpredictability, at least from the user perspective -- they don't always see the underlying/hidden controls and triggers as they type, and when those go awry, behaviour changes.

If some of these problems are indeed within the Mozilla core editor, I hope they can be fixed despite your comment above in #8 about little chance.  These are serious aggravations for some people -- the composer needs to work right.

Meanwhile, I'll keep using "Paragraph" mode for now, checking for changes as updates go by.

Comment 13

[Jorg K (CEST = GMT+2)]

Attachment: Test page showing the bug

I've looked at this a little more. The conversion from paragraph to "body text" inserts <br type=_moz _moz_dirty> which you can see in the DOM inspector.

Lines separated by such <br> elements react a little strange as can be seen in the example, in fact, it's the "type=_moz" that makes the difference.

Ehsan, hi, long time no see ;-) If you have a spare five minutes could you please tell me what those special "type=_moz" elements are about?

Comment 15

[(no longer active)]

Apologies for the delay, I was on vacation/out sick for a while.

This special element is created by nsTextEditRules::CreateMozBR(), and it's generally used as a way to reserve some physical height for empty block elements (such as an empty div) so that its height is enough for the user to be able to put a cursor inside and start typing.  nsTextEditRules::IsMozBR() is used to check for the presence of this element.  You can search for calls to that function to find all of the places in the code where we do something special with the mozbr element.

Also, as you know, new inquiries about the editor should go to Masayuki, not me.  :-)

Comment 21

[Makoto Kato [:m_kato]]

I cannot reproduce this on Thunderbird 60.  Inserting <br type=_moz> is incorrect, so "- convert the text to Body Text by selecting that option in the combo box" or "enter some new text" shouldn't insert/generate <br type="_moz">.  So I want to know how to way that <br type=_moz> is inserted.  (I don't want resulted sample that already has <br type=_moz>).

Comment 22

[Jorg K (CEST = GMT+2)]

(In reply to Makoto Kato [:m_kato] from comment #21)
> I cannot reproduce this on Thunderbird 60.
Me either. Back in 2016 those <br type=_moz> were inserted, no doubt, I can reproduce it easily in TB 52.

All the reports we have are for TB 45 and TB 52. Should we close this?

Comment 23

[Jorg K (CEST = GMT+2)]

Sorry, something went wrong refreshing the BMO page so I inadvertently closed the bug. If you disagree, please re-open.

Comment 24

[Makoto Kato [:m_kato]]

Thanks.  Maybe, masayuki improves some paragraph code, then it may be fixed.

Comment 25

[Jorg K (CEST = GMT+2)]

I think I remember some refactoring/changes/improvement is the way br's are inserted (I don't want to go looking for the bug now).

While we're talking about fixing old bugs, one I hit almost every day is bug 1297069 :-( - Comes with testcase in FF.

Comment 26

[Graham Menhennitt]

I can't reproduce it now either (in 60). So, leave it as closed. Thanks!

Comment 27

[Robert]

This is still happening in the latest 60

I've had it occur twice today, once in a new message and once in a reply.

A new discovery, which may help pin things down: Although inserting a character causes the cursor to jump to the line above, backspacing works normally at the cursor position.