791002 - Message compose window scroll jumps when editing

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[WBT]

Attachment: Example e-mail

See attached example.

Setup options:
A. Open the example from file and hit Forward.
B. Drag the example into your Drafts folder and click to edit the draft message.
C. Drag the example into any folder (IMAP used in my tests) and right-click on the message header, then choose Edit As New.
D. Open the example from file and hit Reply. 

Actions: 
(optional) read first paragraph.
Scroll down to the bottom of the message.

At the bottom left corner of this message, you will see the ends of three vertical lines, indicating reply levels.  Put your cursor at the start of the line which only has the blue bar, and press backspace.  The message scroll jumps to a much higher point in the message, unexpectedly. Usually the top of the scroll is at the top of the purple bar.
Then scroll down to find your cursor.  Click to put it on the first of the two lines that have only a purple bar, and press backspace.

The message again jumps, this time to the top of the green bar.  You can scroll down and repeat this.  You can then scroll down again and put your cursor on the final, empty line, and press backspace, which will also cause you to jump to the top of the green bar.  

Pressing CTRL+Z (undo) after any of those backspaces restores the line break you deleted (as expected), but with the change and the cursor being well below the bottom edge of the visible screen. 

If you use Setup D, you will see how the extra lines got there, but you will have to interpret:
"orange" instead of "green"
"green" instead of "purple"
"purple" instead of "blue" 
when following these instructions. 

The expected behavior is that the line break is removed with no change in scroll, and that the change triggered by either a backspace or undo will be immediately visible, in the visible field.

Comment 1

[Joe Sabash [:JoeS1]]

I tried this step:
"At the bottom left corner of this message, you will see the ends of three vertical lines, indicating reply levels.  Put your cursor at the start of the line which only has the blue bar, and press backspace."
In the Midas Demo, and it produced the same result.This usually means a Gecko core problem.
I would think that on backspace, the cursor should move to the next character in the same quote level. But then, that's just my expectation.

There are many quirks in the Editor code that will probably only get fixed with a major re-write of the code.

Best advice IMO is to learn to live with them.

Comment 2

[WBT]

On backspace, the cursor should move to the previous character position, regardless of quote level.  One common use case for e-mail replies is to put replies inline, so you have many different blocks at each level and they're interspersed with each other; "next character in same quote level" would have things jumping around quite unexpectedly.

Anyway, the cursor already behaves fine.  The scroll is what jumps unexpectedly.  This means that the cursor location is no longer visible.

Saying "just learn to live with all the quirks of open source software" is not a good way to build or maintain adoption.  Increasing usability is.

Comment 3

[Joe Sabash [:JoeS1]]

Perhaps I don't understand your use of backspace inre interspersed comments.
Backspace, of course deletes the previous character as well as moving the cursor.

Certainly interspersed (inline) comments are common in email.
Accomplished by positioning the cursor at the proposed breakpoint and hitting the enter key.

Certainly usability improvements are important, but as a long time TB user,I can assure you that flexibility in method (know the quirks and avoid them) is a very necessary rule to observe.

Comment 4

[WBT]

The cursor behavior in this example is already fine, that's not part of the bug discussion here.
It's the scroll behavior where the bug is, and it is a bug. 

I am also a longtime TB user and know the quirks with TB jumping around, moving text, and changing formatting even of text that's not being currently edited.  Every time, they serve as a reminder that TB and open source software more generally is buggy, not appropriate for the general public on usability, and unstable.  It often takes me quite a while to get it down to a reliably reproducible example that I can use to file a bug report, which is the first set of steps toward making the software better.

Comment 5

[Wayne Mery (:wsmwk)]

Rainier, can you determine whether this, bug 790993, bug 794177, bug 794089 and bug 740927 still exist when using current beta?

Comment 6

[Rainer Bielefeld]

I did a quick test with reporter's sample document and TB Daily 53.0a1 (2016-12-23) (64-bit), I was not able to reproduce scrolling issues. But I did not follow Steps A,B,D correctly, because TB was not willing to show the .eml as inline text (although "inline" is selected in Preferences). So I simply

1. Menu 'File → Open Saved "Scroll Bug Example.eml"'
   » Mail contents shown
2. Menu 'Message → Forward as → Inline Attachment'
   » Mail shown in Composer
3. <Tab><Tab><ctrl+end>
   » brings caret to end of text (behind blue left bar bottom end)
4. <Backspace>
   » Message view scrolls 1 line down (because last line deleted) as expected. 
     No caret visible, but typing "x" shows it in the last line behind blue bar

I gambled a little around editing the text, tried other examples from original report, but never saw unexpected scrolling.

Comment 7

[Wayne Mery (:wsmwk)]

WFM per comment 6