Closed Bug 170292 Opened 22 years ago Closed 4 years ago

backspace key should not change address fields, should backspace only

Categories

(MailNews Core :: Composition, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: andrixnet, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss)

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910

Backspace key will delete characters from an address field (be it To:, Cc:,
Bcc:) and when it arrives at field start, it jumps to the previous one in the
list ( assume multiple addresses listed)

Reproducible: Always

Steps to Reproduce:
1.open mail composition
2.write several addresses, not separated by comma, but on different lines.
3.on the last one press and hold backspace

Actual Results:  
Backspace will delete characters to the start of the line of the field where the
cursor is. When it reaches the field start, it jumps to the end of the previous
address field and continues to delete there (if there are enough keypresses).

Expected Results:  
Backspace should only delete characters on the address field where the cursor
is, it should not jump fields.
For example, Delete key works correctly, it does not jump fields.
I'd say that this is intended behaviour. Backspace (and Delete also BTW) can
be used to delete an address field, but only if the field is completely empty.
Otherwise there would be no easy way to remove an accidentally added field,
I guess.
Backspace & Delete keys should remove the unwanted addressing field.  Resolving
invalid. 
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
verified
Status: RESOLVED → VERIFIED
However, current behaviour introduces an unwanted sideeffect, the one that I 
described:

I am on the second address field and I want to delete some chars from it, or 
all. I press backspace and hold. My key repeat rate is high (30 chars/sec) and 
before I know it, I find that I deleted part of the previous address too.

Backspace should stop at field beginning. Then let the user move out of the 
field (ie with up/down arrows) and this will determine the field removal, it is 
emtpy and user left it. 
However, I'd rather suggest that empty fields in the address block should only 
be removed when the usr leaves the address block. (ie go to subject or 
whatever). 
Current behaviour is annoying because it makes the user retype some of the valid 
addresses he/she previously entered. I can tell you that this caused me a lot of 
frustration and I prefer Netscape 4.x if I have multiple emails to write in the 
address block because of this.

Suggest reopen.
*** Bug 179890 has been marked as a duplicate of this bug. ***
<sigh> didnt find this when I wrote a long bug report (the one marked as
duplicate above).  I think this should be reopened.  While the deletion across
addresses is a useful feature, it should not be so easy to accidentally delete a
long list of addresses.  It violates the principle that anything you type in X
keypresses (without using the ctrl or alt keys) should be un-doable in ~X
keypresses.  It also violates the expectation from users that each box is
treated as a separate typing zone, which can't interact with other boxes
(without hitting tab/enter/using mouse).

Strongly suggest reopening; this is a valid complaint.
As stated in comment #6 : 

It violates the expectation from users that each box is treated as a separate 
typing zone, which can't interact with other boxes (without hitting 
tab/enter/using mouse).

Somebody please take a look at Netscape 4.x mail composition window...
I've seen so many good features in Netscape 4.x redesigned in Mozilla with poor 
results or nasty side effects. This is one of them.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Some of the fields describing the bug are wrong -- I've verified this on both a
windows and linux build of 1.2, but this bug is only marked as Win95 on PCs.  
This bug is the result of a deliberate "feature", not a platform-specific thing.

I enclose some text from the duplicate bug above, in which I suggested some
methods for solving this problem, and note cases where it is particularly bad:


The feature of backspacing across addresses is a useful one, but perhaps some
changes should be made to make it less "hungry" to delete other addresses.  For
example, I suggest the two changes:
- _holding down_ backspace only goes to the left hand side of the current box,
- you are required to hit and release backspace twice in succession instead of
once, to cause a move between an empty address and the address above.  

This would not greatly affect the time taken to delete loads of addresses, it
means it takes three hits of "backspace" instead of two, per address. However,
it would potentially greatly cut down on accidental deletions.

This problem is made worse by the fact that if you use a reply-to address, and
press "backspace" a few too many on the _first_ address, your reply-to address
gets edited/deleted by accident, AND when you finally retype your reply-to and
hit enter, the next address also comes up as a reply-to!  Then you have to start
using the mouse to fix things up, which takes ages compared to typing.
-->varada
Assignee: ducarroz → varada
Netscape 4 gets this right. -> 4xp

Not only does the backspace key jump to the previous field when it runs out of
characters, if the current field is the first field, then the current field is
discarded and the backspace key deletes characters from the *end* of the line in
what *was* the subsequent field. -> dataloss

Users don't deserve or need this kind of surprise behavior. *Maybe* the DEL key
should jump to next (delete current) field and continue deleting, but no way the
backspace key in Win or OS/2 should do this. PC keyboards contain both backspace
and DEL keys because they are supposed to perform different functions. Backspace
should never advance anywhere, particularly to the end of a subsequent field.
Blocks: 176238
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp, dataloss
OS: Windows 95 → All
Summary: backspace deletes characters from all address fields → backspace key should not change address fields, should backspace only
comments #8 had the best solution for this:

1. Holding BACKSPACE deletes address to the beginning of its line, then stops.

2. Releasing and pressing BACKSPACE again deletes that (now empty) address line,
places the cursor on the end of the line above, and continues to delete (if
BACKSPACE is kept depressed).
I don't think the comment 8 suggestion goes far enough, though. The autorepeat
feature shouldn't do more than one thing at a time. If we allow it to delete a
field, then another new keypress should be required before zapping characters in
the formerly previous field.
So what you are suggesting is:

1. Holding BACKSPACE deletes address to the beginning of its line, then stops.

2. Releasing and pressing BACKSPACE deletes that (now empty) address line
(nothing forther happens while the key is depressed - no cursor visible). 

2a. Releasing places the cursor on the end of the line above.

3. Holding BACKSPACE again deletes the "formerly previous field". (we are back
at step 1)
I dont think this bug is still relevant.  I complained about this on 1.2 (see
comments 6 and 8), but on 1.3 which I'm currently using, the behaviour has
changed and its no longer doing this.  I have not checked 1.4 but I dont see why
the behaviour would have reverted. 

In 1.3, when I hold down backspace, it deletes to the beginnning of the current
line, and when I let go, it jumps to the end of the previous line.  This is the
behaviour suggested in comment 8; thank you to the developer who implemented it.

I suggest marking RESOLVED.

PS I still have a gripe - which is that if you type in a reply-to address and
hit enter, the next line comes up with "Reply-To" at the beginning, which is
probably not what you want.  But this different enough to be a separate bug.
Try this version:

1. Holding BACKSPACE deletes characters preceding the cursor until the beginning
of the focused field is reached, then stops.

2a. If no characters remain in the field, releasing and pressing BACKSPACE
deletes the (now empty) address field at the cursor (nothing forther happens
while the key is depressed - no cursor visible). 

2b. Releasing BACKSPACE places the cursor at the end of the field above the
field just removed.

3. Holding BACKSPACE again deletes characters from the (formerly previous)
focused field until the its beginning is reached. (we are back at step 1)
In 1.4rc1 for Linux, OS/2, & W32, backspace deletes everything. When it runs out
of previous characters and rows to delete, it deletes subsequent characters and
rows.
Nope, the latest nightly happily deletes ALL addressess while the key stays
depressed.
(Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b; MultiZilla v1.4.0.4A)
Gecko/20030602)

> type in a reply-to address and hit enter, the next line comes up with
"Reply-To" at the beginning

Excellent point. Please file a bug. (probably should default to "To:")
Please search for such a bug before filing. It should probably default to
whatever preceded "the reply-to", which is not necessarily "to".
I don't understand the complaint. My copy of NN 4.71 behaves exactly as Mozilla
does.
Removing 4xp since NN 4.71 behaves the same way, and I don't think accidentally
deleting part of an email address you have typed meets the criteria of "critical
loss of data" for the dataloss keyword.
Keywords: 4xp, dataloss
I'm not sure how I determined 4.x behaved differently, but this is still
dataloss, as when you hit reply-all, then add an additional address, change your
mind and backspace too far, you can still remove what you didn't type, beyond
what you did type. 
Keywords: dataloss
But it's not critical loss of data. Click on the "Keywords" link to see the
criteria. Sure, you lost an address, but you can get it right back.
Can get it right back how? You think Joe Averageuser knows how? He didn't type
what was removed, why should he have to figure out what was unexpectedly removed
and then figure out how to get it back? I can't think of any other app where the
backspace key can change input fields. That unexpected behavior can be easily
construed as critical. The principle of least surprise is violated. 
I never thought of each line in the addressing field as a separate field before.
They're just separate lines in the same field. That's why they have little
dotted lines instead of borders.

To: someone@foo.com
To: someother@foo.com

is the same as

To: someone@foo.com,someother@foo.com

so backspacing as it works in 4.x and Mozilla is not behacing strangely at all.
I still use Netscape 3 for most email. It makes them all discrete.

To: someone@foo.com
CC: someother@foo.com,foo@foo.com
BCC: stillanother@foo.com
Reply-To: notme@foo.com
Newsgroup: netscape.public.mozilla.general,netscape.public.mozilla.ui
Followup-To: netscape.public.mozilla.ui

should all be entirely discrete fields. BS should not be able to cross the
boundaries. 
*** Bug 239981 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 254402 has been marked as a duplicate of this bug. ***
*** Bug 312043 has been marked as a duplicate of this bug. ***
Assignee: vparthas → nobody
QA Contact: esther → composition
Product: Core → MailNews Core
Bryan, dy think comment 13 is the reasonable solution?  Or is current behavior "not that bad"? See also comment 10.
I think what is described in comment 10 is definitely a bug.  I'm a bit unsure about the behavior change suggested in comment 13. I should try testing the undo for this scenario. I feel like if the undo of the "hungry" backspace were better this wouldn't be a further issue.  Perhaps the undo should consider each line as a natural break point such that it would be easy to fix over deleting.
bug 244516 and bug 244511 have similar issues
I guess this is not a new issue then... I see it has bothered users since 2002 and clearly some users think it is correct behavior.

Add me to the list of those who think it is a bug and is annoying.

In particular, backspacing to delete a TO: address continues due to fast repeat keying to delete part of the Reply-To: address. If not noticed at the time - quite easy to overlook - an email will be sent with an incorrect Reply-To: address.

I did this several times before I realized why and have received emails from numerous users with broken Reply-to addresses (truncated by one or more characters). Guess what? I just checked, and they were all from Thunderbird users.

So it is not just me.

IMHO, backspace should stop at the beginning the line(or field), not move to previous lines(or fields). The Reply-To line is a different field to the To: line in my opinion. Backspace should not start deleting my Reply-To: field when I want to edit the To: address.
Concerning "intended behavior":
If you have several e-mail addresses in one line, it is reasonable, that backspace keeps on deleting until it reaches the beginning of the line.
But in the "new e-mail" window, there are separate input fields for each e-mail address. There backspace should only continue until the beginning of the current input field. This is what a user expects. This is how other software works.

Dear sirs,
I would like to update this. The issue is still present and annoying. If you are in CC field and start pressing backspace to correct error, if you are fast and don't notice whole field is deleted and cursor move to previous field and starts deleting as well.
Cursor must not move to previous field after backspace operation in one field reaches the start of field.

In the re-designed pills implementation for message compose this is just not applicable.

Status: NEW → RESOLVED
Closed: 22 years ago4 years ago
Resolution: --- → WONTFIX

Hello, in which version are we expecting this re-designed pills implementation?

(In reply to Fotis_Greece from comment #38)

Hello, in which version are we expecting this re-designed pills implementation?

That is bug 440377, which says Thunderbird 73.

You need to log in before you can comment on or make changes to this bug.