Windows 10 OS
Thunderbird 91.3.0

Write window:
Problem - Loss of control over text cursor

First test :
Do not type anything - perform the drag and drop of text first.
Highlight text from a webpage eg: any Bugzilla comment in a bug report
Use drag and drop method and drop into a new Write message.

Result:
No evidence of copied text. Completely blank.
Text cursor remains flashing in the first top left position.
No keys nor mouse can move the flashing text cursor.
If you start to type the letters etc will appear; if you use the 'Enter' key and start to type, you discover text appear on another line, but the text cursor itself remains in the original top left position flashing.
If you use the arrow keys to move about and then type, you have no visual idea where that typing will appear until you type.
This means you have no idea where text will appear until you type something.

Image shows flashing text cursor position top left. It remained in that position the entire time I was typing. The true location where the text cursor should be is immediately after the full stop/period before signature.

Second test:
New Write mesasge.
Removed the signature and at this point the flashing text cursor is exactly where it should be at the start top left.
I entereed some text and at this point the text cursor is moving along as I type, so it is flashing immediately after I have type showing where the next typed entry will appear.
I pressed Enter and went to a new.
Performed the drag and drop of highlighted text taken from my previous comment in this bug report.
Nothing has appeared, the drag and drop of text has not occured.
Start to type and the flashing text cursor is not keeping up with me. It is still in the same location where I dragged and dropped and now it is easy to loose where I am if ever start pressing on arrow keys etc.

In the image the flashing text cursor is now stuck on the fourth line where I attempted to perform the drag and drop. In reality it should be at the end of the text after the full stop/period.

Now you get some further weirdness going on.
If I use the 'mouse' I can get the flashing mouse cursor to move to one other location at the end of the first paragraph. - see next image. But that is all I can do within the 'text content' area. I can select to type something in the eg: 'Subject' and all behaves normally.
But back to the content - there is only two locations for mouse cursor position. Where you type is dependent on the real hidden text cursor position.

I've now managed to get the true text typing location back to before the stuck flashing cursor - I know this because there is a ?.
Then I use backspace 3 times:
1: it removes the ?
2: then the flashing cursor moves up to end of first paragraph
3: On last backspace the paragraph is joined together and now flashing cursor has moved to very end of new location of end of paragraph - BUT if I then type ? you will see the true location of the hidden text cursor.

Finally, once I have flashing cursor at end of paragraph with no following text and then I get focus on another program or type in this bug report, when I return to the text and mouse click at end and type the flashing text cursor appears to behave correctly because it has nothing in front of it.
It is not true, select anywhere in the previous typed content using mouse to position text cursor - perhaps to edit mispelt word.
What occurs?
You can type in the location you selected with the mouse BUT the flashing text cursor is still at the end of the paragraph.

If you used the arrow keys and backspace keys etc because you were frustrated etc you could end up anywhere in the email and even ruin previously typed content.

Flashing cursor at end of paragraph after the triple backspace as per previous comment.
Then I type a question mark ?
Note the ? is actually where the true hidden text cursor is located.

Just for clarity - I also tested this in thunderbird Safe Mode with same results.

This problem was initially brought to my attention by another user reporting a different bug.
Testing confirmed I could reproduce bug.

PLEASE NOTE:
If you close that Write message and choose to save as draft (or Save as Draft and then Close), then in 'Drafts' folder select email and click on 'Edit' to reopen in a new Write message, you have full control back and cursor behaves as expected.

Great find Anje, thanks for the report.
Confirming exactly as described (see my screencast), 91.3.0 (64-bit) on Win10 (Windows indicates that there's a pending OS update).
This is seriously bad and broken.

STR

• drag and drop text from external app into empty composition body
• press Enter a couple of times and type
• refocus composition and type
• press Enter a couple of times and type
• navigate with keyboard (e.g. cursor up) and type

Actual

• after drop, nothing: no text appears in composition
• composition window does not have focus after drop
• after refocusing composition, cursor appears, and typed text appears behind the cursor.
• pressing Enter moves the cursor, again typed text after the cursor
• navigation no longer moves the visible cursor, but only invisible typing postion - where the text will appear is now a guessing game

Expected

• dropping text into composition should succeed
• cursor should be behind typed text always
• keyboard navigation must reflect in cursor moves

This is seriously bad and broken (see my screencast).
I was tempted to mark this P1/S1.
Makes editing body text in composition a complete no-op because the visible text cursor gets stuck and won't move any more, whereas the invisible actual insertion point can be moved, so you will never know where you are typing.

Aleca, can you make a plan?
Why does the composition window not get focus after the drop of text?

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

STR

• drag and drop text from external app into empty composition body
• press Enter a couple of times and type
• refocus composition and type
• press Enter a couple of times and type
• navigate with keyboard (e.g. cursor up) and type

Actual

• after drop, nothing: no text appears in composition

This works fine for me on Wayland (linux). There is a bit of a delay before the composition window accepts the drop (i.e. shows the drop indicator), but it succeeds after that.

• composition window does not have focus after drop

Note that, on my system at least, a drag and drop doesn't move focus between windows.

Just wanted to confirm that general symptoms occurred on my linux variant/version as well:

Thunderbird 91.3.0
Linux 5.8.18-100.fc31.x86_64 (fedora)
xorg-x11-server-Xorg-1.20.6-1.fc31.x86_64
xfce4-about-4.14.1-1.fc31.x86_64

I can reproduce this consistently on Windows.
On Linux and macOS for me it works but with some delay, and in some rare occasions the text is not pasted but I never experience the wrong cursor position like in Windows.

This is super annoying indeed.

On my fedora31 linux box, one of the easy ways to run into this issue:

1. Open a new mesg window to write. But, don't click on the new window. It will, by default, put the cursor in the "To:" field.
2. Now, drag an URL from your browser (firefox in my case) into the "compose" pane (without changing the cursor position).

Most likely, it won't copy, and the cursor would stay in the "To:" field. I have however experience success by holding the drag in the compose pane for a long while and it will succeed, sometimes. And, yes, there are times that, there is no cursor to be found, depending on how many times one tries. I understand that MSWindows doesn't have all the window focus options on Linux. I have the 'focus follow cursor' and 'raise window only when click'.

This happens even if you drag text inside TB from an email to the compose window.

Pinging thomas to see if he can test this on Windows.

(In reply to Alessandro Castellani [:aleca] from comment #14)

Pinging thomas to see if he can test this on Windows.

Perfect! This fixes the problem completely. Thank you!
Tested on Win 10, TB 96.0a1 (2021-11-19) (64-bit) with this patch applied locally.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/f9116709e786
Fix drag and drop of plain text in the compose window. r=henry

Comment on attachment 9251493 [details]
Bug 1740711 - Fix drag and drop of plain text in the compose window. r=henry

[Approval Request Comment]
Regression caused by (bug #): bug 1737386
User impact if declined: inconsistent behavior in handling dragged text on top of the composition windows.
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

Comment on attachment 9251493 [details]
Bug 1740711 - Fix drag and drop of plain text in the compose window. r=henry

[Triage Comment]
Approved for beta

Thunderbird 95.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/3d4d91eaf204

Looks good to me using 95.0b4 on Fedora 34 Workstation.

Comment on attachment 9251493 [details]
Bug 1740711 - Fix drag and drop of plain text in the compose window. r=henry

[Triage Comment]
Approved for ers91

Thunderbird 91.4.0:
https://hg.mozilla.org/releases/comm-esr91/rev/d94f44f2be74