GNOME Bugzilla – Bug 669006
Clicking "Not Junk" button should not move to next email
Last modified: 2012-01-30 16:07:04 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=785207 Description of problem: Behaviour change request. Clicking the "Not Junk" button should not cycle to the next message. If you want to mark numerous messages, they can be selected as a set. This change whill reduce the number of keystrokes used in normal email reading, by eliminating one of the places where a message reselect is required to stay on the message. This change also will eliminate anomalous behaviour where marking the last message changes the selected message to the one above instead of the one below when any other message is marked. Version-Release number of selected component (if applicable): Evolution 3.2.3 System is a fully up-to-date clean-install of a Fedora 16 desktop How reproducible: Every time. Incorrect design. Steps to Reproduce: 1a. Select a not-last message in the in-box. 1b. Click the "Not Junk" button. 1c. Observe that the selected message has now unexpectedly shifted down one. 2a. Select the last message in the in-box. 2b. Click the "Not Junk" button. 2c. Observe that the selected message has now unexpectedly shifted up one. Actual results: Extra keystrokes to get back to the selected message. Different undesireable behaviour for the last message and any other message in the folder. Expected results: Selected message stays selected.
Shifting up or down is more-or-less expected, it's to keep the view on the nearest position as it was before changing state of the message, though I agree that it is not necessary to change selected message always. For example, for the Junk/Not-Junk buttons it would be enough to change selected message only if these are pressed in other than Junk folder (for mark Junk) and only in Junk folder (for mark Not-Junk), because only in these folders messages can be moved away due to the status change.
Created attachment 206450 [details] [review] evo patch for evolution; This does what is described above.
(I'm only wondering how many users prefer the current behaviour from the new.) Created commit 0ec1a44 in evo master (3.3.5+)