Closed Bug 122854 Opened 23 years ago Closed 17 years ago

Delete key does not delete message

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: robert, Unassigned)

References

Details

Attachments

(1 obsolete file) 

[My apologies if this is a duplicate, but the only related bugs I found were
specific to the Mac platform.]

Periodically (like, 3-4 times a day) my mail window gets into a state where
selecting a message and hitting the delete key does not work.  Clicking the
delete button does work, though.

Selecting a different mail folder, and then returning to the original folder (my
Inbox) fixes the problem.

This is on Win2000, build 2001122106
QA Contact: esther → sheelar
reporter,
Can you download the recent build and see if this still happens. Also is there
any way of reproducing this? 
I've just downloaded the latest build and will let you know if I see the bug
again.  Unfortunately I haven't seen a consistent way to produce the bug.  I'll
definitely include one if I figure out what is triggering this problem.
email which will not let itself be deleted by Mozilla 0.9.8
I'm not authorised to edit attachments (even though I just added it! ;) and
would just like to apologise and say this attachment really belongs to bug
#122739. I've added it to the correct bug now, must've done something daft, sorry!
Attachment #69635 - Attachment is obsolete: true
I just had a very similar bug with a recent build : 2002060704 running on Win2k.
I did exactly the same opetation : click on a message (3 pane-view), press del
key, nothing happens.

Does not happen every day, though ....

Confirming because I have seen this problem as well. Sometimes from 3 pane I am 
not able to delete the message with delete key.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: sheelar → stephend
This just happened to me in Mozilla 1.2.1, Linux 2.4.x, Gnome + Sawfish, Little
Mozilla 1.2. Never happened to me under Mozilla 1.1. I had a message in my Inbox
selected and focus on the message pane, and the Delete key did nothing. After
backtabbing to put focus on the message header in the header pane, it did work,
and similarly for other messages; it just required the header to be selected,
rather than the body (very annoying when reading & deleting many messages).

After switching to another folder & back, things are back to normal. So I don't
know how to reproduce, unfortunately.
I think I know how to reproduce this now.

I have an IMAP server with the usual folders.

Click on Trash with the mouse. Click on Inbox with the mouse. List of messages
in Inbox appears in header pane. Message pane is empty.

Press F. First message is selected (with focus) in header pane; body displayed
in message pane. Press TAB. Subject is selected. Press TAB. Date is selected.
Press TAB. Message pane is selected (dotted line around it).

Press DELETE. Nothing happens.

Click on Trash and then Inbox with the mouse again. List of message headers
appears; message pane is empty again.

Click in empty message pane. Press F. First message is selected in header pane
(but without focus, i.e. grey not blue in Little Mozilla theme) and body
displayed in message pane. No apparent focus owner: no dotted line around
message pane this time.

Press DELETE. Message is deleted. Next message is selected; this can again be
deleted from the keyboard, etc.

Summary: keyboard DELETE is possible, but only if you first use the mouse to
click once on the message pane!

Note that in the "working mode" (after clicking once in empty message pane and
then browsing to messages), you can Shift-TAB and Shift-TAB back to the
subject/date and TAB back into the message - which then has a dotted border, as
in "not working mode" - but DELETE still works on the message. However, if you
Shift-TAB back to the header pane, giving focus to a message header, then it
will switch into "not working mode". So my guess is that some aspect of putting
keyboard focus on the header pane kills DELETE functionality.

Seems to be a workaround from the keyboard. When in "not working mode", TAB
enough times to get to the groups pane (once, unless there are hyperlinks in the
message body). Then Shift-TAB back into the message pane. Now you are in
"working mode".
Funny, I'm seeing the opposite of Jesse: I'm finding that I have to click in the
thread pane before the Delete key will work.  If I click in the message pane,
then type Delete, nothing happens.
The recent regression might have been fixed by David's checkin today to the
trunk for bug 182808.
this seems to be working fine for me in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030106

I tried comment 8 and when I did 3rd tab and hit delete key
mesg was deleted. I didn't see Akkan's problem in comment 9.

Anyone still seeing this with a recent build?
Re. comment 11 - did you try my steps to reproduce in comment 8 in Moz 1.2.1 as
well? If so, and it worked there too, bummer, maybe a platform problem. If not,
I guess it is fixed? I can download a recent build and try it there if you need
me to; let me know which build to test.
Same bug persists in Moz 1.3 release as per comment #8.
I hit this several times a day lately, because focus ends up in the folder pane
but delete requires focus in the thread pane.  Here's why I hit it:

Click on inbox in the folder pane.  Click on first unread message.  Read mail
for a while.

Click on another folder (say, bugzilla) in the folder pane.  Click on first
unread message.  Read some messages, then notice there's new mail in Inbox
(higher priority.

Click on Inbox and read the new message.  Now click on the bugzilla folder to
continue wading through bugzilla mail.  The last-read message loads into the
message pane, so it looks just like it was before I detoured over to Inbox; but
it's not, because if I hit delete, it won't delete the message, but sends the
delete to the folder pane instead.  Sometimes, this does nothing; other times,
it pops up a dialog asking if I'm sure I want to delete that folder and all its
contents (which of course was not my intent).

So the behavior I currently see can be broken down as follows:

- User misperception: I expect focus to be in the right place for delete to
work, even though I just clicked in the folder pane.  As a programmer I can
understand why focus is in the thread pane and why this happens; and in fact
there is even a visual difference (the folder is highlighted in dark blue rather
than grey when the folder pane is focused); but nevertheless I keep making the
same mistake, and perhaps others do too.

- Part of the reason for the misperception is that there's no way for me to
switch between two folders without as a side effect focusing the folder pane. 
(In NS 4.x this wasn't a problem because I could hide the folder pane and use
the folder dropdown.)

- Mozilla bug: the fact that sometimes I get a dialog and sometimes I don't,
when hitting delete with focus in the folder pane, is a bug (and perhaps should
be filed separately, but I don't know how to reproduce it, i.e. what's different
in the two cases).

Question: Do users really want to be able to use the delete key to delete a
whole folder?  This problem would go away if "delete folder" had a different key
binding from "delete message".
I think comment #14 is referring to an entirely different issue than the other
comments here (incl. my own #8 and #13) and should probably be filed separately.
I can easily see where the focus is supposed to be in the message window; that
is not the problem. The focus is on the message pane, not the thread pane, not
the folder pane, but Delete does nothing.
dupe of bug 72873?
Yes, I think this is a dupe of bug 72873 (at least the symptoms I have seen and
reported here). I also found a better workaround in that bug - press Alt-E to
post the Edit menu then Escape to cancel. Then Delete works as normal.
Robert Keiffer: if you're still reading this, are you still experiencing a 
problem?  If so, is it the same as the problem described in comment 8 (or 
comment 14, for that matter)?

Akkana: The symptoms described in comment 14 require that you have turned on the 
preference "Remember last selected message"; that's how the message appears in 
the window, while the focus remains on the folder tree.  (Me, I can't stand that 
preference being on.)  Do you think it would be better to shift the focus to the 
header pane when the last-selected message is loaded?  That might qualify as a 
new bug/rfe.

The criterion for whether the dialog 'Delete this folder?' pops up depends on 
whether the selected folder is standard (Inbox, Sent, etc.) or nonstandard 
(Bugzilla).  Standard folders can't (or shouldn't, anyway) be deleted.  I think 
your final comment/question in #14 is worth discussing; if DEL with focus in the 
folder pane was the same (Delete Message) as DEL with focus in the message pane 
or header pane.  But for me, I prefer DEL to work on the folder.  (I note in 
passing that if the focus is on a folder, the Delete button in the toolbar is 
disabled, and the menu item reads "Delete Folder" rather than "Delete Message," 
even if it's disabled due to the folder's type.)

I am duplicating Jesse Glick's symptom on Windows 2000, in 1.3 Final and in
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030415

Note that Bug 72873 refers to deleting messages with what is (in Windows and 
Linux) the backspace.  I'm assuming that such behavior is normal on a Mac and 
the events are mapped correctly, in which case, the behavior in comment 8 does 
indeed sound like a dupe.
*** Bug 183721 has been marked as a duplicate of this bug. ***
Note that Bug 183721 has an alternate means of duplicating the symptom described 
here in comment 8.
Hey Mike, yes, I'm still reading this, but I long ago stopped paying attention
to the email reports on this bug (in the process of cleaning out my
notifications folder right now, though).  Anyhow, this hasn't been a problem for
me for quite a while, but I'm using NS7.0 (Gecko/20020823) so I can't
confirm/deny for more recent versions.

Feel free to close this in whatever manner you choose based on the comments from
the other folks.
*** Bug 184069 has been marked as a duplicate of this bug. ***
looks similar to bug 57510
I think the symptom of this bug has been reported in 57510, but I believe that 
bug is primarily about making sure that the Mac's "Delete" key and "Del" key 
(one of which is Backspace on Win/Lin systems) both act to delete the message.

The latter half of 57510 (cmts. 16, 17, 27) are talking about the entirely 
different bug 192780, which has been fixed for a while now.

For this bug, the dupes from comment 19 and comment 22 show the simple technique 
to get the software (in any state) to ignore the (standard) delete key.
Comment 8 in this bug has a more complex means of getting to the same state.
As I noted above, bug 72873 is a likely dupe for this.
This looks like a dupe of bug 57950
No; bug 57950 reports failure to delete by any means of deletion (DEL key, 
toolbar button, menu).  I suspect that bug can be WFM'd.

This bug specifically says the DEL key does not work, the toolbar button does; 
and, this bug is easily reproducible, by following the procedure in comment 8 or 
in bug 183721.
*** Bug 72873 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 205074 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
I have been experiencing a problem like this for several years.  I update
frequently each time hoping it will be fixed.  Now I am using Mozilla 1.8b6 on
linux.  I only experience this on linux (I use win2K at work).

The problem sounds very similar to the description - the keyboard DEL fails to
delete but I can still delete by using the mouse in some way.

This problem seems related to a general problem where keys are ignored for other
actions as well.  The "j" key to mark as junk also fails at the same time as the
DEL key.  Also, I notice the absense of Cut/Copy and Paste functions via the
keyboard, but I can still drag and drop text (in textareas).

I have not found a reliable way to cause this problem to occur or to switch it
off again.  I tried the steps in comment #8, but the DEL key worked for me as it
was supposed to.  It does seem to fix itself eventually, usually.
Same sporadic behaviour on my side for several years, using all kind of
versions, Thunderbird 1.0 and Mozilla 1.8b nightlies for example. I noticed that
it does happen only with my work account (Courier), but not with my private
account (Cyrus).
(In reply to comment #29)

> I have not found a reliable way to cause this problem to occur or to switch it
> off again.  I tried the steps in comment #8, but the DEL key worked for me as it
> was supposed to.  It does seem to fix itself eventually, usually.

I found a reliable way to reproduce the problem and also a way to recover. 
Hopefully this will help someone fix it.  I am using Mozilla 1.8a6 in Mandrake 10.0.

I typically read mail in Mozilla and left click on a link, such as a
slashdot.org news item, to pop up a browser window.  (Sometimes I middle click,
to have it create a new tab, but the bug requires left-clicking to have it
switch windows for you.)  Then if I leave that browser window active and simply
click back to get to my email in a very short time (no more than a few seconds)
the DEL key will no longer work, as well as the 'j' key and probably all other
keyboard commands (e.g. 'f' to move forward).  This will continue until I return
to the browser and select a different tab.  Then the DEL and 'j' keys work again
in the email.

Creating a new tab also clears the bug.
It may only be sites like slashdot that cause the problem (e.g.
http://slashdot.org/article.pl?sid=05/03/03/0316245)
Assignee: sspitzer → mail
Not 100% sure if this is the same bug:

On "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060131 Thunderbird/1.5", build ID:2006013111 -- but not in the nightly of Jan. 29

Hitting "Del" key doesn't anymore move selected message to trash (the Messages List pane being current). Dragging to the trash folder works, as does Right-click -> Move To -> Local Folders -> Trash

Notes:
1. I'm using Thunderbird, not Mozilla.
2. I'm using TB1.5/Moz1.8 Branch builds, not Trunk builds.
3. AFAICT, this is a "solid" bug.
(In reply to comment #32)
> Not 100% sure if this is the same bug:
> 
> On "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060131
> Thunderbird/1.5", build ID:2006013111 -- but not in the nightly of Jan. 29
[...]

Bug is not present in "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060201 Thunderbird/1.5", build ID:2006020104
The main behavior of this bug, as described at comment 8 (Jesse Glick), while reproducible in Moz 1.7.12, is not present in Seamonkey 1.0.x.  Note that the <del> key is not active when focus is on one of the headers in the envelope panel, but it is active when focus is on the message body.

In Thunderbird, the behavior of comment 8 is present in TB 1.5 (bug 341176) but in 2a1-0604, I see the <del> key active when the focus is anywhere in the message pane (including the attachment panel -- bug 315144).


The behavior described at comment 14 (Akkana Peck) is addressed at bug 335034.
I have tested Eudora 8.0.0b1 with Mac OS X 10.4.10. Trying to delete a mail in the Inbox doesn't work with Apple-D or the Menu Entry Message -> Delete.
Hitting "backspace" does work.
(In reply to comment #35)
> I have tested Eudora 8.0.0b1 with Mac OS X 10.4.10. Trying to delete a mail in
> the Inbox doesn't work with Apple-D or the Menu Entry Message -> Delete.
> Hitting "backspace" does work.

Mac would be a different bug.

On windows WFM per comment 33 and comment 34, and current trunk - with the exception of bug numbers noted in those comments.  Issue of delete not working in SM if header is focused is bug 419379. 

original problem is gone.  so => WFM.
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.

Attachment

General

Creator:
Created:
Updated:
Size: