If a search is performed resulting in a list of mail items, and one or more items are deleted by using the DELETE button on the search window, then these items do not get undeleted by an edit->undo operation resulting in the permanent loss of those mail items. This problem is aggravated by the unfortunate position of the DELETE button in the lower right corner where a user might reasonably expect a CANCEL button.

This is intentional. We currently do not support Undo of search ui deletions. I'll look up the bugs relating older bug(s). I don't know if/when we plan to implement this kind of undo.

A couple of older and related bugs: bug 74567, bug 78240

If you don't know how to undo the delete, then please don't offer the delete function on the search window. I have twice lost email items due to this misfeature, and due to the unfortunate position of the button on the search window.

nominating.

Undo a deletion from QuickSearch now works but doesn't display (see new bug 107033). Now that we can undo a deletion from the new Quickie Search, we should probably be consistent and make sure we can undo something deleted from the "advanced" search.

Is this really a nsbeta1+, P2? If yes, then we need to try and targeted to a milestone M1.0 or earlier to make the beta.

Nominating for next release

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

mass re-assign.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

WFM current trunk, unless we're talking Search Messages (which would make this a duplicate)