Red Hat Bugzilla – Bug 919002
when there is no message selected, don't select any message after flip of read/important icon in msg list
Last modified: 2014-01-02 06:01:30 EST
Description of problem: when there is no message selected, don't select any message after flip of read/important icon in msg list The side effect of current behaviour is that if no message was selected when user navigated to the folder, first message gets selected that means typically big jump from most recent messages to the first message in the folder, which can cause big unnecessary annoyance... Version-Release number of selected component (if applicable): evolution-2.28.3-30.el6.x86_64 How reproducible: always Steps to Reproduce: 1. navigate to the folder, make sure that no message is selected (if it is, deselect with ctrl-click) 2. flip read or important flag of another message 3. Actual results: the message that was selected last time gets selected again. If no message was selected before, topmost message gets selected Expected results: no message gets autoselected, view remains exactly as it was Additional info:
Thanks for a bug report. I suppose you flip the flag by clicking into the respective column in the message list. I think the message list tries to select some message when it gets focus, thus user can navigate by keyboard (think of accessibility).
> I suppose you flip the flag by clicking into the respective column in > the message list. Yes. > I think the message list tries to select some message when it gets focus, > thus user can navigate by keyboard If auto-selection can't go away, then the message that was clicked should be selected. Current behaviour can be _very_ annoying if your folder is worth 10000's of messages and it moves you to the least interesting end... > (think of accessibility). Would it be possible to set "default" cursor location where the cursor would appear when user uses keyboard navigation?
Created attachment 710142 [details] evo patch This patch for evolution fixes the behaviour in a way that it selects the message on which are changed flags only if there is none selected in the message list, otherwise it behaves like before. With a reproducer (slightly polished): a) enter a folder, select one message b) deselect it (ctrl+click) c) click in a folder tree on other folder d) return back to the previous folder by clicking in the folder tree e) click in the Important or Read column to change these flags Current behaviour: The first message in the message list is selected New behaviour (with this patch applied): Message on which the flag was changed is selected
I've got quite strong use case for not selecting any message: 0. setup: * local message caching is disabled, evo stores locally just (some) headers * computer has slow and paid-per-data connection to the internet 1. user switches to a folder where no message gets selected (& downloaded --> good) 2. user wants to flip some non-interesting message as read 3. some message gets selected, unfortunately a message with 1 MB attachment 4. user has to wait 5. 1 % of user's monthly 150 MB plan is wasted and all of that because of keyboard accessibility concern that is inherently invalid because user can get to that state when using mouse only... (Points 4. and 5. won't be so severe after patches for bug 949610 will have made it to the builds as UI won't be blocked - point 4. - and hopefully the download will be cancelable - point 5.)
(In reply to comment #4) > I've got quite strong use case for not selecting any message: > 0. setup: > * local message caching is disabled, evo stores locally just (some) headers > * computer has slow and paid-per-data connection to the internet Users with such concerns should have disabled preview panel (View->Preview->Show Message Preview (Ctrl+M)) and open messages to read selectively. That way you can use keyboard too.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1540.html