Open Bug 1291626 Opened 8 years ago Updated 3 years ago

Threads Pane: After mail deletion focus jumps to next mail below deleted one

Categories

(SeaMonkey :: MailNews: General, enhancement, P5)

SeaMonkey 2.10 Branch
Unspecified
Windows
enhancement

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: web, Unassigned)

Details

(Whiteboard: [WONTFIX?])

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:47.0) Gecko/20100101 Firefox/47.0 SeaMonkey/2.44
Build ID: 20160608001333

Steps to reproduce:

1. Sort the mails with the newest mails on top
2. Click on the 2nd mail and delete it by pressing del-key on your keyboard

(you might use your Junk folder for testing this, if you don't want to delete your mails)


Actual results:

2nd mail gets deleted, the previously 3rd and older mail will have the focus now


Expected results:

1st and newer mail should have the focus now, so that you can start deleting your incoming mail from old to new.

In Seamonkey you only can delete from top to bottom. But the mail client should, like some other mail clients, care about your sorting order, so that you'll delete from old to new. E.g. if you have newer mails on top, the deleting order should be bottom to top.
Trying to explain it a little bit better:

If you have 5 unread messages in your inbox, you usually start reading with the oldest one. So I'd click on the 5th mail. If I delete this, it does not make any sense that the focus jumps to older mails i already decided to leave there and not to delete. The focus should jump the the next newer message, which will be the next unread message in that case. (This is what happens if you have the latest mails on bottom).
Effect is reproducible with official en-US SeaMonkey 2.48a1  (NT 6.1; WOW64; rv:51.0)  Gecko/20100101 Firefox/51.0 Build 20160804000913  (Default Classic Theme)  on German WIN7 64bit

a) But I think this is a feature. Behavior "always jump down with focus" so 
   is much more predictable than if the fucus jump direction depends on a 
   sort order
b) I additionally checked Addressbook contacts and History entries (both
   in Sidebar) and Bookmarks (Menu ˋBookmarks → Manage Bookmarks ...ˊ:
   they all work the same way like complained Thread pane, with deletion focus 
   jumps to the list item below
   It would be worrying to have a different behavior in Thread pane.

I see this one WONTFIX

c) I doubt that the current behavior started with SM 2.44

@Reporter:
d) Which are those "some other mail clients"?
e) We would need some really good, comprehensible reasoning before we
   start to think
Severity: normal → enhancement
Flags: needinfo?(web)
OS: Unspecified → Windows
Priority: -- → P5
Summary: focus not jumping to newer mails when deleting with newest date on top → Threads Pane: After mail deletion focus jumps to next mail below deleted one
Whiteboard: [WONTFIX?]
Version: SeaMonkey 2.44 Branch → unspecified
a) I'd say "always jump to next unread/newer message" is also predictable.
b) I don't think that contacts and history entries are suitable for direct comparison, since you don't have unread messages there. But i see the point that programming a different behavior for different lists will make things more complex.
c) Yes, it sure was there in older versions.
d) I'll check that. As far as I see this is the case in K-9 Mail. In fact, Opera Mail and OWA (Outlook Web Mail) also do it from top to bottom only.
e) You could argue that "from old to now" might be more predictable than "from top to bottom", but I now understand that the behaviour also might be different from other list fields then.
c): current behavior already REPRODUCIBLE SeaMonkey 2.10   Mozilla/5.0 
  (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
d): ?
e): "... also predictable" is not a very passionate reasoning ;-)
    Nothing will be changed only because a different solution "also works"

We can leave this one open, wait for votes and so on, but as a SeaMonky-REF this one never will be fixed - I am very very sure.
Version: unspecified → SeaMonkey 2.10 Branch

ok.

Flags: needinfo?(web)
You need to log in before you can comment on or make changes to this bug.