Open Bug 286284 Opened 20 years ago Updated 3 years ago

compose window editor changes its caret position upon entering characters in certain blocks of text

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect

Tracking

(Not tracked)

People

(Reporter: chase, Unassigned)

References

Details

I am editing a 5-7 page document using Thunderbird's compose window and am putting finishing touches on it in one section. The section is italicized and is a part of an indented block of text. Originally, the phrase "may be" was used in the section and I later decided to change that to "will be". I moved my cursor to before the word "be", clicked, and removed "may ". (It is possible I moved the cursor to before " be" and removed " may", I can't remember.) Upon typing "w", my cursor jumped one line up and reset to the left margin and the letter "w" appeared there. I deleted the "w", moved my cursor to before "be", and typed "w" again. This time the same thing happened. I showed mscott who tested entering text into the italicized, indented section. Entering data anywhere in the section led to the cursor being reset to the left margin on the line above the section and the character appearing at the new cursor position. He also tested entering text into another block (selected at random). The character appeared where it should as the cursor did not "jump" on input. This is against Thunderbird 1.0 (en-US 20041206 build) on Windows XP SP2.
Resummarize.
Summary: compose window editor loses my position upon entering characters → compose window editor changes its cursor position upon entering characters in certain blocks of text
To continue my work, I started a new line above the italicized section, made the new line italicized, and was able to fill it out as expected. The old section still exhibits the behaviour of bouncing the cursor up a line (but to the end of the new section). Maybe a sample will help explain this. Before: This is my italicized text that a problem. Cursor placement: This is my italicized text that |a problem. Typing the character 'h': h| This is my italicized text that a problem. Now with the fixed section.. Before: | This is my italicized text that a problem. Typing the new line: This is my new italicized text that doesn't have a problem.| This is my italicized text that a problem. Cursor placement in the old section: This is my new italicized text that doesn't have a problem. This is my italicized text that |a problem. Trying to enter a new character (h) in the old section: This is my new italicized text that doesn't have a problem.h| This is my italicized text that a problem.
I've deleted what text was in the section at this point (so it is empty). Entering any text at the cursor exhibits the same bug. It must be the rules about how the cursor interacts with that section that causes the bad behaviour. After deleting the line on which the text existed and creating a new line, the broken behaviour no longer appears.
Do you have any idea what might have gotten the problem section into that state? I have seen a similar problem with 1.0+0309, but I could not figure out how to reproduce it. In that case, it was a plain text message with quoted text. I had the cursor on the line immediately below the (multi-line) quote, started to type, and noticed that the cursor had jumped to the line above the quote. I think it's quite likely the point where I started to type was still considered "part of the quote". This sort of problem has been around for a while and reported in various guises; see, e.g., bug 131276, bug 216031.
Summary: compose window editor changes its cursor position upon entering characters in certain blocks of text → compose window editor changes its caret position upon entering characters in certain blocks of text
(In reply to comment #4) > Do you have any idea what might have gotten the problem section into that state? No and I agree that's frustrating. Something happened to the state of the data structure representing the block of text over the course of a day (I'd been working on the email for a while and hibernated many times over the course of its composition). Things I might have done to that area of text: * Italicized, then removed the italicized markup, then added it again. * Indented, then unindented. * Started at an unindented portion of text, then indented, and removed the separation between the new text and the old (already indented) text above. Throughout this period I never saved the email as a draft. I never tried to send it. I never shut down Thunderbird.
QA Contact: message-compose
Assignee: mscott → nobody
I don't doubt this issue's existence, but it would be cool to get an .eml file for testing. I have noticed similar funkiness: copy any text from LibreOffice to a composition window. The caret is immediately in the wrong place. Press return and it becomes invisible.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.