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)
Tracking
(Not tracked)
NEW
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.
| Reporter | ||
Comment 1•20 years ago
|
||
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
| Reporter | ||
Comment 2•20 years ago
|
||
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.
| Reporter | ||
Comment 3•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
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
| Reporter | ||
Comment 5•20 years ago
|
||
(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.
Updated•18 years ago
|
QA Contact: message-compose
Updated•17 years ago
|
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.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•