Closed Bug 354778 Opened 18 years ago Closed 17 years ago

message composer mishandles space at end of text (cursor in wrong place)

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: johnwellshardy, Unassigned)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060925 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060925 Minefield/3.0a1 When typing an e-mail message or newsgroup message, if I type a space at the very end of a paragraph when there is more than one line of text, then move the cursor to an earlier line to change something, then return to the very end of the paragraph, the cursor is positioned BEFORE the space when it should be positioned AFTER the space. You can try to move the cursor to the other side of the space with the right-arrow cursor-key or the [End] key, but it responds as if the space is not there. The [End] key will place the cursor before the space. The right-arrow key will move the cursor to the next line if there is additional text after the paragraph in question. If you are at the absolute end of the text, the cursor will not go beyond the space. This leads you to believe that there is no space there. But if you begin typing from that point, the space will reappear and the cursor will jump to the correct position. If you believe that there is no space there, then add one, you will discover that there are now TWO spaces there and you will have to go back and delete one (or have crummy looking text). These problems have existed for months, perhaps a year or more. I'm using the latest-trunk nightlies for Windows on a 64-bit version of Windows XP-Pro and a 32-bit version of Windows XP-Pro, both with with all the latest patches and updates. No themes, no extensions. Thank you. Reproducible: Always
Duplicate of bug 143950?
(In reply to comment #1) > Duplicate of bug 143950? > I don't think this is a duplicate. In bug 143950, the requirement is to FILL a line, then try to add a space. The space is mishandled. In bug 354778, the requirement is to type a space as the last character of any line of text. It does not have to be a full line of text. Then move the cursor to an earlier or later line of text as you would do to make corrections, then return the cursor to the point AFTER the last space at the end of the line you were working on previously. One of three things will happen, depending on the mood the editor is in: 1. The space will still be there, and the cursor will be positioned correctly after the space. The editor is behaving properly. 2. The space has been deleted by the editor (without the user's knowledge or permission), and the cursor has been positioned one character earlier to compensate for the deleted space. You end up thinking "I could have sworn I typed a space there before I went off to make some corrections...". So you type a space, then continue with your typing, and all is well (except that you had to replace the space that the editor deleted). 3. The space has NOT be deleted, but the cursor has been positioned one character earlier anyway. Again, you end up thinking "I could have sworn I typed a space there before I went off to make some corrections...". So you type a space, then continue with your typing, only to discover that there are now TWO spaces there. The original space was NOT deleted, but the cursor was positioned to lead you to THINK it was deleted. This bug relates to how the editor deals with a space as the final character in a line of text. The line of text can be almost any length. In my opinion, if the user types a space, the editor should put it there and never mess with it. I have read some other bug reports, and it sounds like there are some odd theories as to how spaces at the end of a line should be treated by an editor. In my opinion, if the user types a space, treat it like any other character. Don't modify it, don't delete it, don't try to outsmart the user, and do whatever else is necessary to make the editor work correctly with a space at the end of a line. Thank you.
Is this bug being worked on? Any progress to report? Any further information required? Thank you.
It is now March 28, 2007 and this bug still exists. Is there any progress being made? Is anyone working on it? Is there any additional information that I can provide? Thank you.
Confirming on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070327 Thunderbird/3.0a1 ID:2007032703 [cairo] (this is trunk only, regression from 2.0)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Summary: Message composer mishandles space at end of text → message composer mishandles space at end of text (cursor in wrong place)
Version: unspecified → Trunk
The analysis in comment 2 appears flawed. I seriously doubt that the space has been deleted in any case; if johnwellshardy wants to argue the point, he has to provide steps-to-reproduce that don't rely on magical thinking like the "mood the editor is in." See bug 235223 -- there have been changes in this area between the branch and the trunk, which is probably the point at which the "regression" (I don't agree on that point either) occurred. I opened bug 363624 about this same problem, and if I do say so myself, my description, steps-to-reproduce, and analysis are superior. If someone wants to insist that the "older bug is the one that gets duped to," well, go ahead, but I'd make the dupe the other way.
Here is a simple example of some of the problems: 1. Open an editing window. 2. Type the letter "a" as the first and only character on line #1, followed by a line-feed ("Enter") to force the cursor to the beginning of line #2. 3. Type the letter "b" followed by a space on line #2. 4. Use the Up-Arrow key to move the cursor to line #1. 5. Use the Down-Arrow key to move the cursor back to line #2. 6. The cursor should be positioned after the space on line #2, but it is positioned after the letter "b" instead. 7A. Use the Right-Arrow key to try to move the cursor beyond the space. The cursor remains after the "b". 8A. When you resume typing from that point, the next letter that you type is positioned directly after the "b" with no space in between. The space has been deleted by the editor. But, instead of steps 7A and 8A, try steps 7B and 8B instead: 7B. Use the End key to try to move the cursor beyond the space. The cursor remains after the "b", giving the impression that the space is gone. 8B. When you resume typing from that point, the space re-appears and the first character that you type is positioned after the space. If the first character that you type is a space (to make up for the space that seems to have disappeared) followed by one or more characters, you will have TWO spaces there. The editor did not delete the original space, but it led you to believe it was deleted because it would not let you move the cursor beyond it. If you use the same editing window over and over with these tests, you should make certain that you have deleted all characters before starting a new test. I use the Backspace key to get back to position #1 on line #1, and then I also use the Delete key to make certain that there are no characters or spaces left after the cursor to mess with the tests. There could be a space or hidden formatting character there that you can't see. Failing to do this may be why the editor seems to have mood swings. There may be other factors that I have missed. The space is being mishandled. In steps 7A and 8A, the space has been deleted by the editor without the knowledge or permission of the user. In steps 7B and 8B, the space has not been deleted, but you are lead to believe it has been deleted because you cannot move the cursor to the point after the space. But the space has not been deleted. It re-appears when you resume typing. The editor should treat a space like any other character. I believe this a different set of circumstances than described in bug #363624. There may be a related cause (or there may not), but the conditions are very different. Therefore, in my opinion, neither bug is a duplicate of the other.
Even simpler: 1. Open an editing window. 2. Type the single character "a" followed by a space. 3. Press the Home key. 4. Press the End key. The cursor should move to the point after the space. Instead, it goes to the point after the "a" and before the space. It appears that the space is gone. 5. Type "b". The space reappears between the "a" and the "b". If you type a space before the "b", you will now have two spaces. If you use the Left-Arrow key and Right-Arrow key instead of the Home key and the End key, the space will really be gone for good. The editor mishandles the space.
I've been seeing this for some time, and frequently end up adding duplicate spaces in my emails as a result. Unlike comment 8, I haven't been able to reproduce a situation where the space is "gone for good", because if I follow the instructions, but then hit return after the visible character, the whitespace does show up on the new line. I'll try to define a regression point asap.
On Windows, this bug regressed between the 20060420-10 and 20060421-12 trunk nightlies. My steps to reproduce are simply: - open a mail compose window - in the message field, type 'a' then a space then hit enter - hit the left arrow to move the caret back to the end of the first line (or use mouse) - in 'good' builds, the caret will be placed after the whitespace, in bad builds it abuts the 'a'. Typing another letter after the 'a' reveals the hidden whitespace, which is drawn between the letters The regression range casts suspicion on the check-in for bug 132561 (see bug 132561 comment 36), which would make it related to (but of course not the same as) bug 336408.
Blocks: 132561
Er... I bet it in fact _is_ the same as bug 336408.
Depends on: 336408
Even better, then :) Sorry, the desc of that bug made it sound a bit different.
I surely wish it would get fixed. It's over a year old - over 1.5 years if your regression estimates are correct. A text editor that cannot properly handle spaces is inexcusable. Is anyone even looking into this problem? Thank you.
This works fine for me on linux/latest trunk.
Still broken on the latest-trunk "version 3.0a1pre (2007110903)" for Windows.
I have a similar problem in Composer. Frequently the cursor doesn't move when I press the space bar. When I press it again, two spaces appear in the code: a real space and an  . The only way to move the cursor without getting a double space seems to be to just type another character (in Normal mode). This problem is even older than 2 years, because I already had it in Netscape Composer v. 7. Thank you in advance for solving it, - Frank
johnwellshardy: still see this on windows trunk? Still WFM on linux trunk.
Assignee: mscott → nobody
Spaces seem to be handled properly now under Windows. I am grateful to the person or persons who fixed it.
->WFM then. (For linux the fix was bug 336408.)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.