Closed
Bug 170292
Opened 22 years ago
Closed 5 years ago
backspace key should not change address fields, should backspace only
Categories
(MailNews Core :: Composition, defect)
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.
Comment 1•22 years ago
|
||
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
Reporter | ||
Comment 4•22 years ago
|
||
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. ***
Comment 6•22 years ago
|
||
<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.
Reporter | ||
Comment 7•22 years ago
|
||
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 → ---
Comment 8•22 years ago
|
||
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.
Comment 10•22 years ago
|
||
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.
Comment 11•22 years ago
|
||
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).
Comment 12•22 years ago
|
||
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.
Comment 13•22 years ago
|
||
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)
Comment 14•22 years ago
|
||
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.
Comment 15•22 years ago
|
||
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)
Comment 16•22 years ago
|
||
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.
Comment 17•22 years ago
|
||
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:")
Comment 18•22 years ago
|
||
Please search for such a bug before filing. It should probably default to
whatever preceded "the reply-to", which is not necessarily "to".
Comment 19•22 years ago
|
||
I don't understand the complaint. My copy of NN 4.71 behaves exactly as Mozilla
does.
Comment 20•22 years ago
|
||
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.
Comment 21•22 years ago
|
||
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
Comment 22•22 years ago
|
||
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.
Comment 23•22 years ago
|
||
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.
Comment 24•22 years ago
|
||
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.
Comment 25•22 years ago
|
||
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.
Comment 26•21 years ago
|
||
*** Bug 239981 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Comment 27•20 years ago
|
||
*** Bug 254402 has been marked as a duplicate of this bug. ***
Comment 28•19 years ago
|
||
*** Bug 312043 has been marked as a duplicate of this bug. ***
Updated•17 years ago
|
Assignee: vparthas → nobody
QA Contact: esther → composition
Assignee | ||
Updated•17 years ago
|
Product: Core → MailNews Core
Comment 29•16 years ago
|
||
Bryan, dy think comment 13 is the reasonable solution? Or is current behavior "not that bad"? See also comment 10.
Comment 30•16 years ago
|
||
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.
Comment 31•16 years ago
|
||
bug 244516 and bug 244511 have similar issues
Comment 33•14 years ago
|
||
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.
Comment 35•6 years ago
|
||
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.
Comment 36•5 years ago
|
||
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.
Comment 37•5 years ago
|
||
In the re-designed pills implementation for message compose this is just not applicable.
Status: NEW → RESOLVED
Closed: 22 years ago → 5 years ago
Resolution: --- → WONTFIX
Comment 38•5 years ago
|
||
Hello, in which version are we expecting this re-designed pills implementation?
Comment 39•5 years ago
|
||
(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.
Description
•