595197 - When using Backspace key in "Edit in Text Mode" of e-mail, deleting one space deletes all continuous spaces/Tabs instead

Status: RESOLVED DUPLICATE of bug 592592

(MailNews Core :: Composition, defect)

Description

[David Simpson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9 ( .NET CLR 3.5.30729)
Build Identifier: 3.1.3

Send an e-mail to yourself with text body "  test   test   test" (with multiple spaces between words).  After receiving it, select Message/"Edit Message as New".  Now if you try to use the Backspace key to delete just one space in the message body, it will instead delete all spaces.

Reproducible: Always

Steps to Reproduce:
1.Send email to yourself with text body "test   test" (3 spaces between words).
2.After receiving it, select Message/"Edit Message as New".
3.Now try deleting just ONE space between words.  Instead of one space being deleted, ALL spaces are deleted.
Actual Results:  
Message body:  "testtest"

Expected Results:  
Message body:  "test  test"  (two spaces between words)

Comment 1

[Erik Harris]

This doesn't just happen in "edit as new."  It happens in new message and replies, too.  Additionally, if you put two spaces and a character, hitting backspace removes the character AND one of the spaces. If you put THREE spaces and a character, hitting backspace deletes the character and two of the spaces.

In your example, if you type "test   test" (three spaces), and then hit backspace four times, you'll have "test " (one space) instead of "test   " (three spaces).

This just started in 3.1.3 (I'm using it in Win7 Pro x64). Needless to say, this behavior makes fixing space-based typos a lot more disruptive to one's typing flow, and is really irritating.

Comment 2

[Eric Hill]

This doesn't just eat extraneous spaces when backspacing over a word, it will also eat a space and the last character typed if it hasn't already eaten spaces. If you type "foo   " (with any number of trailing spaces) and hit backspace, it will delete the spaces *and* the last 'o'. Totally contrary to the Principle of Least Surprise and completely unacceptible. Unsetting layout.word_select.eat_space_to_next_word helps with this to some degree, but all in all I consider the simple act of backspacing in Thunderbird to be broken right now.

For what it's worth, I spent some time combing bugzilla and release notes and haven't been able to find any reference to this change.

Comment 3

[Benjamin Melançon]

Problem confirmed on Thunderbird 3.1.3 for Mac OS X as well: Two deletions when two spaces are involved, instead of one, when pressing delete (backspace).

This is extremely annoying for all of us who place a proper two spaces after our periods ;-)

1.  Type:  Hi.  We...
2.  Go back to between the W and e and press backspace, because you need to change the W to an H, say.
3.  End up with:  Hi. e...   -- we've lost a space, because it deleted the W *and* a space.

If this behavior is intended, it is an unfortunate misfeature.  If i see two spaces to delete, i will press backspace two times.  Same with three spaces.  If i have more whitespace to delete, i can double-click to select it, or use option+backspace.  No matter what, I don't need my e-mail program changing the way typing works on my computer.

Could someone with privileges mark this confirmed and change the title to reflect its occurrence across all e-mail body-editing fields in Thunderbird?

Comment 4

[Koray Sahin]

I've observed this behavior with Thunderbird 3.1.3 on both Windows 7 and OSX.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Major symptom can be said like next:
At compose window of text mode of Tb 3.1.3,
- Continuous whitespaces(Tab, 0x09, Space, 0x20) is probably held like next;
  <span>TabTabSpaceSpaceTabTabTabTab...</span>
  <div style="display:inline;">TabTabSpaceSpaceTabTabTabTab...</div>
- A "Continuous whitespaces" is removed by BackSpace, as if it's single space.
- If "Continuous whitespaces" is placed at left most position of a line,
     [CRLF]<span>TabTabSpaceSpaceTabTabTabTab...</span>{Cursor-Pos}xxx...
  [CRLF] just before "Continuous whitespaces" is removed by BackSpace.
This doesn't occur in Tb 3.1.1.

Cause may be next change of (c-2) by Tb 3.1.3 on <pre> in HTML mode.
(a) Text Mode of Tb 3.1.2 & Tb 3.1.3
    Tab == Tab(0x09)
(b) HTML Mode, other than <pre>, Tb 3.1.2 & Tb 3.1.3
    Tab == 8 x 0x20
(c-1) HTML Mode, <pre>, Tb 3.1.2
    Tab == Tab(0x09) : Same as Text Mode
    BackSpace == Remove single character or a Tab just before cursor position
(c-2) HTML Mode, <pre>, Tb 3.1.3
    Tab == 8 x 0x20  : Same as other than <pre> of HTML mode
    So, BackSpace is different from Tb 3.1.2.
    BackSpace == Remove single space just before cursor position

If next data is typed at <pre> of HTML mode, and data is copied to text editor by Copy&Paste, following is observed. (Tab=0x09, #=Space=0x20, [CRLF]=0x0D0A)
(Case-1)
AAATabTabTabBBBTabTabTabCCC[CRLF]
TabTabTabCCCTabTabTabDDD[CRLF]
=> Ctrl+A, Ctrl+C at HTML composer, Ctrl+V at text editor
AAA########################BBB########################CCC[CRLF]
Tab###############CCC########################DDD[CRLF]
(Case-2)
AAATabTabTabBBBTabTabTabCCC[CRLF]
TabTabTabCCCTabTabTabDDD[CRLF]
=> Delete three Tabs before CCC of second line, insert three Tabs before CCC
=> Ctrl+A, Ctrl+C at HTML composer, Ctrl+V at text editor
AAA########################BBB########################CCC[CRLF]
########################CCC########################DDD[CRLF]

Because Tab is kept as Tab in case-1, following problem can be observed also on <pre> of HTML mode of Tb 3.1.3.
> [CRLF] just before Tab is removed by BackSpace.

Above are repoerwd to a forum in Japan by some peoples.
Confirming.

Comment 6

[Mark Banner (:standard8)]

It should be stated that comment 3 only occurs in the plain-text composition mode and not html. Although I've seen some weird things in HTML mode that I've not tracked down yet.

Getting a regression range would be useful (even just down to nightly builds).

Comment 7

[WADA:World Anti-bad-Duping Agency]

Quick check result about major symptom of comment #5, with trunk nightly builds I happened to have downloaded.
No problem.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100513 Shredder/3.2a1pre
Problem occurs.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100604 Shredder/3.2a1pre

Comment 8

[WADA:World Anti-bad-Duping Agency]

Regression range.

No problem.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100522 Shredder/3.2a1pre

Problem started to occur.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100523 Shredder/3.2a1pre

Comment 10

[(no longer active)]

FWIW, this was a regression from bug 336104, which should be fixed on Lanikai as of tomorrow's nightlies.

Comment 11

[Erik Harris]

It's great that this bug is being tracked, and presumably fixed, in 3.2a1pre builds, but is it safe to assume that this fix will also get incorporated into 3.1.4 or 3.1.5? Since this bug didn't exist in the 3.1 builds until 3.1.3 (or 3.1.2 at the earliest), it should be addressed for non-alpha/beta/RC users well before 3.2 is released at some point in the relatively distant future.

Comment 12

[Mark Banner (:standard8)]

Yes, this will be fixed in either 3.1.4 or 3.1.5, we are already tracking the core bug.

Comment 13

[WADA:World Anti-bad-Duping Agency]

Problem has been fixed by Tb 3.1.4. Thanks to developers for quick resoving.