Closed Bug 1930677 Opened 1 year ago Closed 1 month ago

Undo data loss in composer window: format change followed by Ctrl-Z deletes text

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Version:
Thunderbird 128
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: postiffm, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

128.4.2esr (64-bit)
0. Create a "New Message." Click into the body of the message.

  1. Type a short line, enter, and another short line.
  2. Select the second line. Apply a new format, say Preformat, to it.
  3. Ctrl-Z.

Actual results:

The selected text disappears. Ctrl-Y will not bring it back.

Expected results:

The text should have went back to its previous format, not disappeared.

I have experienced similar behavior in the message compose window over the past several years. This time I am able to reproduce it every time.

Variation: type two short lines as above, select all with Ctrl-A. Change from Paragraph format to any other format. Type Ctrl-Z. The SECOND line of text disappears, and the first line remains in the format you chose, but it does not go back to the previous format.

128.4.3esr (64-bit) gives the same result.

On the variation, I realized my report was incomplete. If after experiencing the data loss of steps 1-3 (the main bug report), then you manually retype line 2, Ctrl-A, change format from Mixed to some other format, then hit Ctrl-Z, the FIRST line of text disappears. Something about the sequencing affects which line disappears. I am guessing if you fix the first problem, all variations will also be fixed.

128.5.0esr (64-bit) gives the same result.

Sometimes the data loss is subtle. If you type two very short lines in the body of the email, and then press Enter so there is a third blank line at the end, and then Ctrl-A, change format, and then Ctrl-Z, what happens is that the THIRD line disappears. But this line was blank, so it may be easy to overlook that data was lost since it was only a whitespace line.

Summary: Format change followed by Ctrl-Z deletes text in editor → Data loss in composer window: format change followed by Ctrl-Z deletes text in editor

Again, compose a new message and type two short lines. Note that if you change the text from Variable width to Courier, say, then Ctrl-Z works to undo that. Or if I format the text as bold or underlined or centered or bulleted or numbered, then Ctrl-Z works correctly as well.

It seems that it is only when you change Body Text/Paragraph/Heading n... and then hit Ctrl-Z that the bug happens.

128.9.1esr (64-bit) has the same bug.

In fact, if in the message compose window you type a single line, highlight, apply a style to it, then hit Ctrl-Z, that single line disappears and you have nothing left in the compose window.

I learned from bug 1521821 that Thunderbird uses the Mozilla core editor also used for Firefox. I can reproduce the above error here, following the exact same steps:
https://www-archive.mozilla.org/editor/midasdemo/

This bug is possibly related to bug 1354359.

Summary: Data loss in composer window: format change followed by Ctrl-Z deletes text in editor → Undo data loss in composer window: format change followed by Ctrl-Z deletes text

I did not write this before: Not only is the second line of text deleted, the line which remains is still in in the CHANGED format, not the original format. So actually undo does NOT undo the format change, AND it deletes the second line of text. Two bugs for the price of one.

Hello. Should a moderate-to-high 'severity' not be set for this bug? (I request info from Wayne Mery because he is the only Thunderbird maintainer of whom I have heard.)

Flags: needinfo?(vseerror)

S3 seems appropriate, maybe S2 because I have lost important paragraphs of carefully composed text due to this bug.

postiffm, thanks for reporting. However, frequent postings of "version xxxx has the same bug" is not going to motivate anyone - it actually tends to demotivate, so please avoid doing this.

You are quite right that this is a Core issue. Undo issues - Thunderbird reported and Core reported - and compose issues more generally, are longstanding. So severity in this case is unfortunately not going to be a vehicle to speeding up a solution - the more likely scenario is some day a decision will be made to make a major investment in the core code or replace Thunderbird's message compose code wholesale. We're not there yet. Until then, small strides are not impossible, but infrequent.

Flags: needinfo?(vseerror)

@Wayne Mery: you accept that the issue is severe. So why not set a higher severity value, thereby indicating, at a glance, that the problem _is _severe? What harm could that do?

Preformat

I don't see Preformat anywhere in Thunderbird compose. Do you mean rewrap?

There are a number of undo / redo bug reports - https://mzl.la/4hSPUgY.

Does yours match to one of these:

  • Bug 1708266 - When composing a reply, undo will not restore message body content inadvertently deleted
  • Bug 1868050 - Undo after changing paragraph style causes text deletion and forgets undo history
Flags: needinfo?(postiffm)

I do not mean rewrap. In my Compose window (titled Write: [subject]), there is From, To, and Subject. Below Subject, I see a pull-down for Body Text, a pull down for Variable Width, text color selector, set font size, smaller font size, larger font size, Bold, Italic, Underline, etc.
In the Body text pull down, there are these options:
Body Text
Paragraph
Heading 1..6
Address
Preformat <== this is the example I used, but you can choose any style on the list, hit Ctrl-Z, and it will delete the last line of text.

If this toolbar is missing from your compose window, it seems you are using a different view or toolbar options or something.

My bug is not the same as bug 1708266 but I am 99% sure that I have experienced that bug, with great frustration after my fingers went into automagic mode and accidentally deleted text. I could not get it back, so had to re-type. It is not frequent, but it has happened.

My bug is likely the same as bug 1868050. And I can reproduce that bug easily. When reporter Jim Garrison says that the first line of text disappears, that is the same behavior as when I say above that my last line disappears. My description is a generalization of his. Because he only changes the format on one line, his first line is the same as his last line since there is only one line. My bug is 100% reproducible and has fewer steps to reproduce. Based on the description, I am almost positive that if you fix one of the two bugs, the other one will also be fixed.

Version 140.4.0esr (64-bit)--bug is still present.

In version 153.0.2, I can no longer reproduce this bug.

Flags: needinfo?(postiffm)
Status: UNCONFIRMED → RESOLVED
Closed: 1 month ago
Resolution: --- → INVALID

Thanks for the update.

Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.