User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 When deleting mails with the delete-key thunderbird 0.9 does not allways move to the next mail in the list but sometimes (about each 10th) it does select none at all. one then has to manually select a mail with the mouse or the arrow-keys. this worked in every version but in 0.9 there is this problem with IMAP and POP3 accounts. Reproducible: Sometimes Steps to Reproduce: 1. have some mail in a folder 2. delete a/some mail with the delete-key 3. delete a/some next mail with the delete-key Actual Results: sometimes it selects "none" instead of the next mail Expected Results: select the next mail

I can reproduce this if I press <del> rapidly, perhaps quickly enough that the delete for the current message is sent before it has a chance to display in the preview pane. If the preview pane is hidden, the next message is consistently selected. TB 0.9, Win2K.

*** Bug 268396 has been marked as a duplicate of this bug. ***

I can always reproduce this behavior in my environment. It will happen to me 100% of the time if I press the delete key before the newly selected message is finished downloading. The message selected (but not downloaded) is indeed deleted, but then the current selection is set to nothing. Very annoying indeed! Client: Thunderbird 0.9 on Windows XP SP1 Server: Cyrus IMAP via SSL (latest server version)

I am seeing the same problem with Thunderbird 1.0 on Linux and Windows, connecting to Courier IMAP server. It is happening in normal use, e.g. when reading a mailing list and deleting messeges after reading.

*** Bug 273830 has been marked as a duplicate of this bug. ***

confirming. bug #272452 may be a dup of this one.

*** Bug 301388 has been marked as a duplicate of this bug. ***

*** Bug 277983 has been marked as a duplicate of this bug. ***

Per the last dupe, this symptom occurs if the delete key is processed while the message is being loaded. See bug 264951, bug 183394.

*** Bug 311559 has been marked as a duplicate of this bug. ***

Can you reproduce this with a trunk build? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/

Yes, it´s still there with a trunk build, at least under Linux

*** Bug 264951 has been marked as a duplicate of this bug. ***

Bug 183394 has been fixed. Please verify with a current trunk build that this behavior has been solved; if so, mark this bug as a duplicate of that one.

*** Bug 271395 has been marked as a duplicate of this bug. ***

This also happens on Linux trunk and OS/2 1.8 branch builds, very annoying.

No response from reporter, duping. *** This bug has been marked as a duplicate of 183394 ***

This is happening in SM branch.

(In reply to comment #18) > This is happening in SM branch. which: SM 1.0 or SM 1.5 (as in gecko 1.9?)

As I wrote in comment 16: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8) Gecko/20060319 SeaMonkey/1.1a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060304 SeaMonkey/1.5a

Felix: when you saw that a Thunderbird bug was being flagged as a dupe to another Thunderbird bug, you were out of line changing it to a Core bug in the first place (especially under Database, which this definitely does not qualify for), at least until some resolution was achieved. You should have opened a suite bug, with a pointer to 183394. I guess that's what we'll have to do with this bug, now that you've thrown your spanner into the works. I don't know whether the patch at 183394 is TB-specific or not, but this problem is not occurring under TB. I'll let the suite guys figure this out.

that patch is tb specific, but I think it will work in the suite.

I didn't see this as being flagged to TB prior to my changing it to core. The way I've since read the history on 183394 it was originally core but was changed to TB. Had that been left alone and a core fix made at the time there would have been no reason for me to do anything with this bug on 2006-03-06 except to dupe it to 183394. Then again, I wouldn't have seen the broken behavior and so wouldn't have noticed or done anything at all with either.

Hopefully this will fix it by fixing bug 243532 in a different way. * Backed out bug 243532 * Resets the next view index when the thread pane selection changes * Caches the next view index when deleting, because onDeleteCompleted triggers a selection change.

Comment on attachment 323291 [details] [diff] [review] Proposed patch It turns out the problem I was having was not testing the action that this fixes. See comment #25 for patch details.

Comment on attachment 323291 [details] [diff] [review] Proposed patch I toyed around a bit after applying the patch, especially testing "hold down DEL key for several seconds and see what's happening". Observations: - not influenced by this patch: while mass-deleting this way in LF in the main window, I get no visual feedback - not influenced by this patch: while mass-deleting on IMAP with delete model 'mark' in the main window, the results are pretty much arbitrary - some are marked as deleted, some not, some several times (you can watch the deletion mark toggle) - influenced by this patch: the delete action doesn't get interrupted, since the selection stays now - mass deleting in the search window results doesn't work at all anymore, the selection is lost after the first deletion - I suppose you need to patch SearchDialog.js as well?

I've just upgraded from Netscape 7 to SeaMonkey 1.1.9 on MSWindow 2K, and this bug is _the_ most painful aspect of SeaMonkey, since deleting emails is the most common emailing activity. Deleting is noticably slower than Netscape, and pressing the delete key repeatedly will quite easily gets ahead of the deletion, leading to overshoot, and greatly raising the chances of the focus being lost. [ Given the speed of the hardware, disk and graphics card, the GUI interactivity is quite disappointing. ]

I'm a bit confused by the comments in this thread. (Maybe I'm just too tired.) But I'm using Thunderbird 2.0.0.17 and have long had the problem that I thought the subject line described. I'll start reading messages and deleting them to move to the next message. But after deleting multiple messages, when I just quit a message and go back to the list view, there's no indication anymore of where I am in the remaining list.

The problem is supposed to have been fixed in Thunderbird 2.0.0.2 by bug 183394 (attachment #208341 [details] [diff] [review]) and bug 326846 (attachment #212279 [details] [diff] [review]). It is not obvious to verify that the fix is correct, since this is an intermittent bug. AFAIK, the problem has never been fixed in SeaMonkey; the two attachments mentioned above are relatively small patches, it ought to be feasible, even easy, to port them as one combined patch. However Neil's patch here (attachment #323291 [details] [diff] [review], r- by Mnyromyr) uses a different approach than what was used in Thunderbird. Neil, I guess that whoever finally (if ever) fixes this bug will have to discuss the respective merits of both approaches with you. I usually delete mail by "Move to ▶ Trash" rather than by hitting Del so the fact that I haven't seen this problem means nothing. Especially since when I have several messages to delete together I use Ctrl-click or Shift-click followed by a single move-to-trash operation. "Assignee" mail@seamonkey.bugs is the default QA for MailNews:General. I'm assuming that someone forgot to "Reset" the assignee at some point in the past. Feel free to re-add it if my assumption was wrong.