User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 I insert the next and previous buttons into the single message window. The buttons take me to the next and previous unread messages, when what I want is to have them iterate over the next and previous messages displayed in the window bar. This also includes iterating over filtered / searched for mail. Reproducible: Always Steps to Reproduce: 1. Add next and previous buttons. 2. Click next or previous. 3. Actual Results: Not the message I want.
I'd like to vote for this enhancement but it doesn't appear that we're able to vote. This behavior SHOULD BE the default! The current behavior makes TB almost unusable. I nearly switched back to OE out of frustration but I luckily discovered the Buttons! extension. We shouldn't have to install an extension to get this behavior. We should install extensions to enhance and customize the application, not fix it. This is something that really needs to be fixed. The current behavior is unintuitive and very annoying, especially for users who are switching from other mail clients or even users of other applications that include Next and Previous buttons. This implementation seems non-standard strictly from a user interface standpoint. I may be wrong, but this just seems to detract from TB's usability.
I agree -- this behavior isn't logical, and in fact, takes a while to understand. My experience is that I have about 120 mail folders, most of which have no new messages. The first time I tried the next/prev buttons, I was in my inbox, and there were no new messages in it. I clicked on next, and was taken to a folder about 50 away in the list; it took a long time for me to figure out that it's because it was the first folder in the list that had an unread message. Confusing.
*** Bug 253970 has been marked as a duplicate of this bug. ***
Agreed - I ALMOST posted in the TB Bugs forum about this because I thought the Next and Previous buttons were broken; it's not clear unless one hovers the mouse over them that they imply "unread" messages. <br> These are probably dupes of this bug/feature request: https://bugzilla.mozilla.org/show_bug.cgi?id=262728 https://bugzilla.mozilla.org/show_bug.cgi?id=242561 https://bugzilla.mozilla.org/show_bug.cgi?id=251945 RW
This bug seems to be platform independent, as I found it on Linux, then checked on my wife's windows 2000 PC and found it there too. I completelhy agree with the comments describing it as a serious bug. After using the "customise" option to install the next and previous buttons I thought something was broken when they did not work as expected. I wasted a lot of time trying to work out whether I had done something wrong. It should be a simple fix as the functionality is already there -- I discovered on a hunch that the 'f' and 'b' keys do exactly what I expected the 'next' and 'previous' buttons to do. (I tried 'f' and 'b' because they are used on a number of linux utilities! But you can't expect windows users (like my wife) to be familiar with such conventions.) As someone who works quickly I did not think of using the 'hover' mechanism to find out what the buttons were meant to do since when I installed them they were labelled 'previous' and 'next' not 'prev.new' and 'next.new' or 'prev.unread' etc., and I thought 'next' meant 'next'! Aaron === www.cs.bham.ac.uk/~axs
*** Bug 289684 has been marked as a duplicate of this bug. ***
*** Bug 251945 has been marked as a duplicate of this bug. ***
*** Bug 262728 has been marked as a duplicate of this bug. ***
Bug 295552 is an alternative to this enhancement and discusses still other alternatives.
IMHO there should be two sets of buttons - "next unread"/"previous unread" as at present, and also a regular "next"/"previous". Users can then use whichever set suit their way of handling mail. Further, each of these should either "do something" if there is no next / previous message, or be disabled (greyed out). Being enabled but performing no action leads users to believe that the buttons "aren't working at all" (see dupes...). In Outlook (2002), the behaviour I'm used to is that "next" on the last message will close the message window.
howdy y'all, my tbird info ... Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 - Build ID: 2005120115 the next/previous buttons are NOT intuitive as has been pointed out. until you actually stop and hover on them, it is not at all apparent they are really "next/previous UNREAD" buttons. i've had two people simply refuse to use tbird until i "fixed" the problem by installing the buttons! extension. while two sets of buttons - as with the above ext and as suggested by others here - may be a bit much, a user pref to let me decide the behavior is not that difficult, it seems. meanwhile, the buttons! extension here ... http://www.chuonthis.com/extensions/buttons.php ... provides the REAL next/previous buttons that tbird fails to give us. take care, lee
*** Bug 332040 has been marked as a duplicate of this bug. ***
G'day all. I have 'updated' to Thunderbird version 3 alpha 1, Build 20060413, and the extension for the "real" buttons does not work. The extension for version 1.5 is not compatible with the updated version. When I did use version 1.5, the "real" buttons were 'just what the doctor ordered'. It is a shame that the programmers for Thunderbird are not listening to what the users want. The inclusion of these buttons would enhance what is a great email program. Take care and keep safe, Grant.
Ron Hunter in mozilla.support.thunderbird had a good idea of making Shift+click perform a different action. ie. click on 'Next' = goes to next unread message Hold down Shift as you click on 'Next' = goes to next message regardless of read status. Or switch the two. Personally, I use next/previous *unread* /way/ more than next/previous read. It's not that I don't navigate between read messages. If you're going to use the mouse, the next/previous messages are usually already on the screen to click on.
I just came across this bug while searching for something else, but you all probably want to know: In Thunderbird 2.0 beta 1 (20061206) there are new buttons for Back and Forward, apart from the familiar Previous and Next. They even have a little drop-down arrow showing the Subjects of a number of messages in the given direction (back or forward). So, now you can choose what behaviour you want by choosing the buttons. In this beta version, the buttons are not always made active correctly, although the keyboard shortcuts (b and f) work fine.
I am sorry, but these buttons do not work the way I thought they did: they work similar to the Back and Forward buttons in most web browsers, thus retreating to the messages that you viewed before. By the way: Aren't there extensions that add buttons for B and F?
I would think there must be extensions that implement butttons that do the equivalent of go | next | message, go | prev | message.
I think the buttons extension does it.
This behaviour still happens at Thunderbird 2.0 beta 2. It has not to be a bad behaviour, but it should be customizable, at least via the Configuration Editor, or better via a check box. By the way, the Buttons extension works in this version.
Is anyone actually going to fix this?
Created attachment 271853 [details] [diff] [review] Proposal patch Here's a patch for making the buttons navigate between next/previous messages regardless of unread state. This is much more obvious behavior as the default. For those who want to get navigation between unread messages, then the buttons extension can provide that.
I don't think we're going to change this behavior by default - that's not very nice for the people that use those buttons.
Created attachment 271857 [details] [diff] [review] Revised proposal patch
Personally I think the Shift+click to toggle read/unread navigation suggestion from comment 14 would make sense.
I agree that it's not the best solution for those who use the unread behavior, but it makes much more sense for the legions of users who try to use the buttons but give up because they can't figure out what's going on due to weird results.
Is it necessary to have *two* buttons, each of which goes to a different unread message? That is, is the position of the unread message with respect to the current message important? If not, replacing both the current Next and Previous (unread message) buttons with one “Show Me An Unread Message” button might be a good idea. (The toolbar icon could be a closed envelope.) (In my experience the Previous button only works sporadically anyway. For example, it doesn't appear disabled when no message is selected, despite doing nothing. (Incidentally, is there a bug number on this issue?)) If this is done, new Next and Previous (unread or otherwise) buttons could be added.
With two buttons marked with a "left arrow" and "right arrow" icon, the basic assumption is that after pressing "right arrow" you can get back to where you were by pressing "left arrow". Not only is this basic user interface assumption violated, but also there is absolutely no way to get back to the message that you just came from within the message window. Next/previous *unread* message are the more advanced function, which more advanced users are likely to wish to use. The *default* behaviour should be the simpler, better understood, and in my opinion more useful "next/previous message".
over the course of time, the icons have lost some of the visual clues that they would go to the next unread, although even now, on Windows at least, there's a double >>, implying that it's not just a simple "next message". In any case, I'd be perfectly happy with this scenario: 3 icons - next unread, next, and prev (I agree that prev unread is superfluous, goofy even) By default, we could have next and prev icons What I'm arguing against is changing the functionality of the existing "next unread" icon to become "next". That would be surprising to users of the next unread icon.
I think that the current behavior is creating more surprise than changing their behavior back might cause in the long run. Also, you should factor in the surprise that new users will experience when they use the existing buttons for the first time. Sometimes it is best just to change something because it is right. I think those other users would understand; provided there is a mechanism to retail the behavior in the event they actually prefer it. Kinda like user-preferences!
Maybe my memory is too long. We've had this behavior since Netscape 4.0, and there have been more complaints in the last couple months then there were in the first 10 years. But I'm willing to change the default for new users - I just don't want to break existing users.
> 3 icons - next unread, next, and prev (I agree that prev unread is superfluous, > goofy even) This sounds like a good solution. Users who had Next Unread keep it with the same icon, although the text for it will change from "Next" to "Next Unread". Two new icons get added for plain next/prev. All 3 icons will be options for customization. Users who had Previous Unread on the toolbar are chastised by their foolishness, and have the button taken away from them. ;^> > By default, we could have next and prev icons Note that right now the (unread) next/prev buttons are not on the toolbar by default. The user has to customize the toolbar and add them. This should probably continue.
Sounds good to me. Make it so! ;-)
> 3 icons - next unread, next, and prev (I agree that prev unread is superfluous, > goofy even) That would be good. Or at least changing the name of the buttons for clearer ones, so users that expect a "next message" don't complain any more for strange jumps :)
I'm not sure what would happen if we removed an icon from the theme - we might have to write some code to remove it gracefully from the toolbar if the user had customized it to include the prev unread icon. Not sure if that would be harder than just leaving the icon for it in the toolbar palette. In any case, this becomes mostly a theme problem - adding icons for the prev and next buttons, and writing a little glue code similar to the code in Jeff's patch.
(In reply to comment #34) > I'm not sure what would happen if we removed an icon from the theme - we might > have to write some code to remove it gracefully from the toolbar if the user > had customized it to include the prev unread icon. Not sure if that would be > harder than just leaving the icon for it in the toolbar palette. I'll take a look and see what happens in that case. If it's a problem and the fix for that is too convoluted I'll just leave the prev unread icon in there. > In any case, this becomes mostly a theme problem - adding icons for the prev > and next buttons, and writing a little glue code similar to the code in Jeff's > patch. Is there someone in charge of themes? I'm not particularly artistic, but I would imagine I could make icons for plain next/prev that look something like the unread next/prev, but with minor differences. Also, how do you submit binary patches?
mscott's more involved with the themes - we have a contributer who does most of our theme work. I'm not sure how you submit binary files, other than just attaching them. But again, Scott would know better.
Comment on attachment 271857 [details] [diff] [review] Revised proposal patch minusing in favor of getting new icons.
noting the 30 votes, nominating wanted-thunderbird3
This is an issue worth looking into but we are focusing our TB3 efforts on only a few areas. Moving off wanted-thunderbird3
Comment on attachment 271857 [details] [diff] [review] Revised proposal patch in light of the r-, clearing sr?
This is my first time posting to Thunderbird. I was glad to see this enhancement listed because it is one of only a few issues I have with Thunderbird. Overall a great program, but only moving to the next unread is really annoying. The fact that this was first reported over 6 years ago & doesn't have an active post for 2 years. Anything going to be done?
howdy y'all, since the buttons! addon is abandonware now, i use this ... - RealPrevNextButtons https://addons.mozilla.org/en-US/thunderbird/addon/159030/ does the job until the devs decide to implement the 3-button idea mentioned in c28 above. take care, lee
David, what about basing the behavior on a pref for now? Can I try it?
Why a pref? I think comment 28 is spot on.
Ok, I can probably look into implementing that harder version too.
Created attachment 576270 [details] [diff] [review] patch implementing comment 28 Ok, this is my implementation of comment 28. It does this: 1. current "Next" button (id="button-next") is kept, just changes its label to "Next unread" 2. current "Previous" button (id="button-previous") is kept, but its tooltip and function is changed to mean "previous message" (read/unread). 3. new button is added (id="button-nextRead"), with label "Next" and tooltip and function meaning "next message" (read/unread). 4. buttons "Next" and "Next unread" use the same icon so far (I have done it in linux gnomestripe theme, can do the other ones if this is accepted). This solution does not add or remove any icons from the theme. It does not even remove anything from the toolbar of the users using the buttons (just the function changes slightly for "previous" button). Would this be acceptable? Would point 2. upset existing users? Or should I really remove the existing "previous" button and add a new one so that users see something has changed and need to re-add it? Maybe it would then need the migration code David mentions and that is something I am not able to code.
howdy :aceman, speaking purely as a user [since that's all i am [*grin*]], this is _exactly_ what i want from this bug. item 3 in comment 50 is a prefect fit for my use. i can see that a new icon for item 3 would possibly be useful. it aint needed for any of my uses. thank you for your work! [*grin*] take care, lee
Thanks for pointing to the RealPrevNextButtons extension (it seems it is outdated too). I looked into its source to see what needs to be done. My version is visually similar, just that I offer only 3 buttons instead of 4.
Comment on attachment 576270 [details] [diff] [review] patch implementing comment 28 Review of attachment 576270 [details] [diff] [review]: ----------------------------------------------------------------- Obviously, we'll need icons for the other platforms, but even barring that... I know a few people who use the reverse-date view, and the previous button instead of the next button, so changing the behaviour of the previous button without giving them a way to get the, uh, previous behaviour back seems like a lose. And even giving them a new "Previous Unread" button, while technically possession the same functionality, takes up so much more space in the "Icons and Text" mode that I'm not really happy with it. I think I would prefer to have new icons for one of the sets, or have the same icons, but make the text on the toolbar just say "Previous" and "Next", if that makes any sense to you. Thanks, Blake.
I am not sure I understand why we'd need icons on other platforms. I try to use the existing ones. It the css I updated not for all platforms? I could make 2 sets of buttons. But I haven't understood what they should be labeled. And also how do you propose to migrate the existing users? Just leave them as they are (maybe just relabel) and add the new (next read, previous read) buttons to the palette and let users pick them?
Comment on attachment 576270 [details] [diff] [review] patch implementing comment 28 clearing review request based on ui-r -
The Windows build showed a blank "Next" icon… The buttons in the customization screen should be labeled "Previous", "Next", "Previous Unread", and "Next Unread", but on the toolbar, they should be "Previous", "Next", "Previous", and "Next", respectively. (Flexible Space and Mail Views already have functionality like this, where what's in the customization screen differs from what's in the toolbar.) Existing users should maintain existing functionality (because we're not removing the functionality), so since the current buttons take people to the Next Unread and Previous Unread messages, they should continue to do so (with re-labeling, but not in the toolbar), and add the new buttons to the palette, letting users pick them if they want. Sound good?
Yes, thank you very much! I'll look into implementing that. But I'll do it with reusing the existing icons. If new icons are wished later, then it can be done in a new bug and by somebody else. If anybody can be assigned to make those icons and knows how to update the themes. I offer to make the necessary css updates with him once he lands the icons in the appropriate files. Now I see why the icon is missing in Windows. I write it myself in comment 50, that I implemented it only in gnomestripe ;)
Created attachment 578422 [details] [diff] [review] patch implementing comment 53 What about this? (Still doesn't have the Windows icons, but I ask about the concept.)
Comment on attachment 578422 [details] [diff] [review] patch implementing comment 53 Yep! That's what I'm hoping for!
Comment on attachment 578422 [details] [diff] [review] patch implementing comment 53 David, would you accept this too? It implements all 4 buttons instead of 3. Does not affect existing users. The new buttons (prev, next) have new identifiers and need to be added to the toolbar. Do you agree with this? I will then do the final patch with icons defined for all platforms.
Now when I look at it, the current patch would affect existing users as it renames button-next to button-next-container (I copied this pattern from mailviews button) so it would remove the buttons from existing users' toolbars. I can leave that original identified unchanged. Consider that fixed.
Comment on attachment 578422 [details] [diff] [review] patch implementing comment 53 I don't see an icon for the next and prev button, on the default windows theme, but other than that, it seems good, thx.
Comment on attachment 578422 [details] [diff] [review] patch implementing comment 53 Looks good! Please wrap the lines in css at reasonable length though.
David, I didn't do Windows theme for now (much work) before I got confirmation you are OK with 4 button instead of 3 that you wished in the past. Thanks, so I can move forward now and implement the icons for Windows and Mac too and clean the patch up.
Created attachment 595132 [details] [diff] [review] patch implementing comment 53, adding icon defines for qute and pinstripe Please test the theme on Windows and Mac OS X as I can't test it there.
Comment on attachment 595132 [details] [diff] [review] patch implementing comment 53, adding icon defines for qute and pinstripe I can only check it for linux too, so please have someone else check that win/mac are ok. Looks good code wise though, r=mkmelin We can do it as a followup but it would be nice to have slightly different icons for the two versions, i can see myself using both next type of buttons.
Yes, see comment 57. I'll file it soon.
Comment on attachment 595132 [details] [diff] [review] patch implementing comment 53, adding icon defines for qute and pinstripe It seems bwinton is back so he can finish this:) I think he has a Mac, maybe Win too.
Comment on attachment 595132 [details] [diff] [review] patch implementing comment 53, adding icon defines for qute and pinstripe I agree about the slightly different icons being an improvement we want, but I'm happy to check this in the way it is and fix that later. ui-r=me! Thanks, Blake.
Thank you to all who helped me here.
mailnews.nav_crosses_folders defaults to one (ask for user confirmation) in 13.0a1 (20120304). The Previous and Next buttons ignore whether a message is read, but nothing happens when you are at the beginning of a folder and press the Previous button or at the end of a folder and press the Next button. Ditto if I set it to zero (cross folders/groups without asking). In both cases I restarted Thunderbird after changing the setting. I tested under Vista with the default theme. I also tested in safe mode. Please clarify whether mailnews.nav_crosses_folders is now obsolete. Personally I never found that feature useful, but I want to update the MozillaZine documentation on that setting.
I reported this bug years ago and finally abandoned Thunderbird in favor of OE6. Just upgraded to Windows 7 and had to go with Thunderbird. Sadly this bug/feature is NOT fixed. Obviously I checked and see that the issue has been tagged as resolved. Not true. It can't be that hard to allow navigation with a button to the next message be it previous up or down. Would also be nice to have a button that allows "open in new Window" instead of right clicking with the mouse. just sayin... Kevin
This is fixed starting at Thunderbird 13 (now in Aurora channel). Do you use that version? Also, you need to rightclick the toolbar, choose customize and choose the version of the buttons you want. It now offers both the "prev/next unread" and also "prev/next (any)" versions.