The upgrade from "From"/"Recipients" to "Correspondents" hasn't gone well, to say the least. It's so bad that it's actually *impossible* to automatically roll back in general; if a user had the From and Recipients columns shown, they're *both* removed, and replaced with "Correspondents", which 1) shows less information, and 2) makes it so we can't tell what the old columns were. In the interest of maintaining user preferences, let's just remove the upgrade code entirely. I don't think we can do much to help people who already upgraded, but there might be some small things we can do. We can also look into making an add-on to help users restore their old column states.

For those coming here wondering how to fix their columns' settings, please read the following (from bug 1152706): (In reply to UpperBear from comment #53) > Do not despair -- I, too, was appalled to find all my dozens of folders > switched automatically to the Correspondents column in lieu of the From and > Recipients columns after the 45.0 upgrade. But the change can be backed out > (and made to stay out) by these steps that worked for me: > > 1. Use the Config Editor to create a new preference named > mailnews.ui.upgrade.correspondents and set it to false. This will prevent > the change from happening automatically in the future. Here's the path to > do that: > Tools > Options > Advanced > General > Config Editor > Click past any warning message about using the Config Editor. > Right-click anywhere below the headings of the "about:config" dialog and > choose New, then String. > Type mailnews.ui.upgrade.correspondents for the preference name and click OK. > Type false for the string value and click OK. > Verify that the new preference was set and close the "about:config" dialog. > > 2. Set one folder in the Local Folders tree to the desired column selections > and spacing via the "Select columns to display" icon at the far right of > column headings bar. > > 3. Use "Apply columns to..." under the "Select columns to display" icon to > copy the selections of the current folder to all other folders and children. > Here's the path: > Apply columns to... > Folder and its children > Local Folders > Local > Folders > Click on the *second* "Local Folders" and then OK in the "Apply changes?" > dialog. > > You will need to repeat steps 2 and 3 for any other folder trees you have > besides Local Folders.

This removes the upgrade code entirely. Perhaps for 52, we could try again and provide an easy way to back out, but let's at least stem the bleeding for now.

I've had releng disable updates to 45.0 for now, on the assumption that we might be taking this for 45.1 and don't want more users getting affected until then

Reference: Bug fix 1152706 @Jim Porter "Since this bug is already marked RESOLVED, it's not a good place to track future work; things will just get lost." So we are saying here that when Mozilla makes a mistake and screws up an upgrade, we have to file a *NEW* bug report? We can't ask them to correct THEIR MISTAKE under the original bug fix report? The status of a bug report stream can not be backed to NOT RESOLVED? Why? It should be able to be if something gets screwed up. How do we keep the information that is divided across multiple discussion and bug report threads straight? That means we have to track back or forward through multiple fixes to find out what is going on. Those who will be looking for a fix to this mess and who get referred back to *this* thread by the link in the upgrade completion page, and those who have been following *this* discussion in *this* bug fix thread, then have to jump to another to follow how Mozilla is going to fix it? Why? Hmm. Jim, this does not seem to make sense from a view of *communication* with the user base. Please revise your view and continue to track the progress under the bug 1152706 discussion, not in this new one. We need to insist that the problems generated by this fix be fixed under this bug report. Please cancel this new one, or revise it to point back to 1152706 and close this one, in order to keep all the material on this situation and its resolution(s) in one place. The errors like this should be fixed under the original bug report, not some new one that is off in la-la land. Doing otherwise seems much more like "things will just get lost". Why not simply make an entry in the old bug report discussion that the bug fix is being returned to the ASSIGNED status for further work, and continue to work the problem under that original bug fix. By the way, I also should have stated in my previous note there that I also have used more than two dozen completely different operating systems (every implementation of DOS and Windows since MS-DOS 1.2 (including IBM-DOS and several other DOS clones, CP/M, OS/2, and more than 200 different utility programs) and every implementation of Wordstar, WordPerfect, Word, Excel, and most of the rest of panoply of Microsoft products up to and including Publisher, and dozens of 3d party vendors' products. I know good interfaces, and I have suffered through a number of terrible ones, particularly those from Apple and Corel. The worst ones are those that do not allow the user to customize how things in utilities are presented. And in future, ask some of us who have specialties in human interfaces and communications what we think of changes ("IMHO, we should force a UI change onto the user.") like this, and how best to implement them. Relying on programmers to make such decisions without reference to people who have experience designing user interfaces and easing people into using new versions is like asking a brain surgeon to determine what to do to fix a slashed face. The difference is that the brain surgeon probably will refer to a cosmetic specialist, while a programmer will think (s)he can do it alone. If you don't believe me, ask me sometime to recount a few of the interface and security issues we discovered in UNIX while going through Cray Research's UniCOS. As just one example, in 1980 a senior programmer there told me flatly (and with an entirely serious, straight face) that "No one who is not a programmer EVER should run a Cray. If you can't type instructions into a command line, then you have no business logging in on one. *No Cray op(erator) should need a graphic interface.* Those are for babies and dummies." Talk about wearing blinders and having one's head up in the clouds ... Regards - John Fairbairn Senior Communications Specialist Rush Creek Research Company

I already replied to this in bug 1152706, but for the sake of completeness, I'll reproduce it here: (In reply to John from comment #78) > So we are saying here that when Mozilla makes a mistake and screws up an > upgrade, we have to file a *NEW* bug report? I already filed a new bug report. You don't have to take any action. As mentioned above, that report is bug 1268325. > We can't ask them to correct THEIR MISTAKE under the original bug fix report? The status of a bug report stream can not be backed to NOT RESOLVED? Why? It should be able to be if something gets screwed up. Bugzilla is a place for developers, QA, release engineers, etc to track the progress of work. It's easier to do so when each changeset to the Thunderbird codebase has its own bug. Among other things, this makes it easier for releng to figure out what commits need to be uplifted to or backed out from which branches. The tracking flags used by releng can only be assigned on a per-bug level (not a per-patch level), so creating a new bug gives us the ability to keep track of its status more easily. > How do we keep the information that is divided across multiple discussion and bug report threads straight? It's easy to copy and paste the relevant comments from one bug to another, as I've done with the instructions on how to disable this "upgrade". > Hmm. Jim, this does not seem to make sense from a view of *communication* > with the user base. Please revise your view and continue to track the > progress under *this* bug discussion, not a new one. That's not how we work on the Thunderbird team, and I won't make life harder on the already-busy releng team just to preserve this bug. They have a hard enough job as it is, especially since everyone who works on Thunderbird does so with their own free time. > And in future, ask some of us who have specialties in human interfaces and > communications what we think of changes like ("IMHO, we should force a UI > change onto the user.") this, and how best to implement them. I'm actually a UX peer for Thunderbird (meaning I have the power to approve or deny UI/UX changes), and am in fact the submodule owner for the "Folders and Message Lists" component. Had I been more closely-involved in bug 36489 (which originally added the upgrade code), I would not have allowed it to land without a better opt-out path for users. To prevent things like this from happening again, I'm drafting an email to discuss policy changes in Thunderbird that will require a closer inspection of code which changes users' defaults. If you're interested in following along with this discussion, you can subscribe to the tb-planning mailing list: <https://mail.mozilla.org/listinfo/tb-planning>.

Comment on attachment 8746351 [details] [diff] [review] Remove the upgrade code It would be sufficient to just set the preference to "false". I'd prefer a one line patch that changes the preference and I would welcome a complete solution once the dust has settled. In general we need to make the user-interface consistent. Users need to be given the choice on whether they want the "Correspondents" column or not. If the answer is yes, the following needs to happen: 1) Upgrade existing folders to the new column (with the existing code). 2) When restoring the default view, use this column. 3) When creating a new folder, use this column. If the answer is no, the following needs to happen: 1) DO NOT upgrade to the new column. 2) DO NOT use the column when restoring the default. 3) DO NOT create new folders with the new column. A one line change is OK for immediate damage control, but the upgrade code is needed in the more consistent solution. I'm happy to r+ if you can convince me that the complete removal of the upgrade code is necessary. Politically I would like to state the following. I personally raised this issue on tb-planning: https://mail.mozilla.org/pipermail/tb-planning/2015-April/003762.html I asked for caution not to force new unwanted features onto the user. I raised bug 1152706 and I suggested to remove the auto-upgrade (attachment 8590457 [details] [diff] [review]) or have it switched off by default (attachment 8591029 [details] [diff] [review]). In all of that, I was overruled.

> I'm happy to r+ if you can convince me that the complete removal of the upgrade code is necessary. Even for people who might be ok with the upgrade in general, the behavior is wrong. If you have "From" *and* "Recipients" in a given folder, the upgrade code replaces *both* with "Correspondents", which results in information loss. Now, you only see "From" *or* "Recipients". I was actually tempted to flag this bug with the "datalossy" keyword as a result. Given that the upgrade code doesn't do the right thing in all cases, I think we should remove it for the time being.

(In reply to Jim Porter (:squib) from comment #8) > If you have "From" *and* "Recipients" in a given folder, the upgrade > code replaces *both* with "Correspondents", which results in information > loss. I thought that's the hole idea: In folders where you collect e-mail from and to a specific person (like I do), the new column saves space and merges two columns into one. Isn't that intended?

I am a user who does like to have both the "From" *and* "Recipients" columns visible in several folders. In my view, the slight gain of space across the line is clearly outweighed by the difficulty of seeing at a glance exactly who the senders and recipients are when the "Correspondents" column replaces those columns. Some people may find the trade-off useful for their purposes. But, as has been made loud and clear by the comments in bug 1152706, the choice of whether to use the "Correspondents" column should be left entirely to each user and should not be imposed by default in either existing or newly created folders.

Here is my solution. The new functionality goes behind a preferences whose default is "off". So nothing changes for the user. If enabled, the upgrade will take place and the default columns (for new folders and when resetting) will contain the new column. Or we could remove the upgrade altogether since it only happens once. If you 1) open the folder without having the preference set, 2) then set the preference and 3) visit it again, no upgrade will take place. Or we could remove the upgrade and leave the preference set to "on" so the feature would only show in new folders and could also be disabled by changing the preference.

We had a drivers discussion about this issue. What we want to do is to go ahead with a 45.1 beta build to the beta channel, with the existing code without this patch. But we are still open to including this patch in 45.1 release, which we hope to build next week. We had hoped that the beta could be a full release candidate, but we don't have to be rigid about that.

Comment on attachment 8746576 [details] [diff] [review] Hide correspondents behind a preference Even if we make the upgrade opt-in, I think we'd want to change the upgrade process. For a minimal change, I think we should adjust the logic to the following: 1) Only replace "From" with "Correspondents" if the folder is an incoming folder and there's no "Recipients" column visible in the list. 2) As above, but for "Recipients" in outgoing folders. This is much more likely to result in the expected UI for users, and I think it would address most of the actual concerns I've seen. For a more-proper way of doing this, I think we should put this change into a "migration wizard" (we used to have one around 3.0) and then upgrade *all* the folders at once. The current lazy strategy isn't in the best place, in my opinion.

(In reply to Jim Porter (:squib) from comment #13) > 1) Only replace "From" with "Correspondents" if the folder is an incoming > folder and there's no "Recipients" column visible in the list. > 2) As above, but for "Recipients" in outgoing folders. This is getting way to complicated, no user will understand this. Let's remove the upgrade as you suggested in the first place. People who want the column can use it. What about mail.threadpane.use_correspondents? Good idea? True or false?

I'm not sure yet. On the one hand, it may be wise to avoid using Correspondents as the default: any user who downgrades will lose that column entirely, and now they have no From/Recipient info in the affect folders! On the other hand, we don't usually support downgrading anyway. The pref is probably ok, but let's set it to false on the 45 branch and true on comm-central. That way, when 52 comes around, more people will get the Correspondents column, but they'll still be able to roll back to 45 without causing loss of essential UI elements.

OK, now with conditional preference value.

Oops, I'll fix the trailing space in the next round.

Comment on attachment 8746697 [details] [diff] [review] Hide correspondents behind a preference and remove the upgrade code (v2) Review of attachment 8746697 [details] [diff] [review]: ----------------------------------------------------------------- r-, but only because of the way you set the prefs. Everything else looks good. ::: mail/app/profile/all-thunderbird.js @@ +336,5 @@ > +#ifdef NIGHTLY_BUILD > +pref("mail.threadpane.use_correspondents", true); > +#else > +pref("mail.threadpane.use_correspondents", false); > +#endif I don't think this is the right logic. It's not a question of what *channel* the user is on, but what *version*. On the 45 branch, it should be false. However, when 52 is released, it should be true. I'd recommend just making two patches: one for comm-central and one for uplift to 45. ::: mail/base/content/folderDisplay.js @@ +444,4 @@ > correspondentCol: function (viewWrapper) { > + if (Services.prefs.getBoolPref("mail.threadpane.use_correspondents")) { > + // Don't show the correspondent for news or RSS where it doesn't make sense. > + return viewWrapper.isMailFolder && !viewWrapper.isFeedFolder; Don't feel you need to do anything about this here, but I think we should allow the correspondents column in NNTP. It doesn't actually work right now (outgoing messages show a blank field), but I bet we could fix that. I'll file a bug. @@ +461,5 @@ > + // No recipient column if we use correspondent. > + return false; > + } > + // recipientCol = To. You only care in outgoing folders. > + return viewWrapper.isOutgoingFolder; Nit: you have trailing whitespace here.

OK, patch for trunk (TB 49), Aurora (TB 48) and Beta (TB 47).

Column not visible in TB45 unless explicitly enabled.

https://hg.mozilla.org/comm-central/rev/d6980e5266a1 OK, for trunk, the correspondents column is enabled, but there is no automatic upgrade. Branches will follow.

Comment on attachment 8746703 [details] [diff] [review] Hide correspondents behind a preference and remove the upgrade code (v3) We plan to land the other patch on ESR45, so we need to make TB 47 and TB 48 consistent.

Comment on attachment 8746704 [details] [diff] [review] Hide correspondents behind a preference and remove the upgrade code (v3) - ESR45 only Although this is not a debacle (according to Kent on tb-planning), I think we decided to roll out the correspondents column a little more carefully. Here's the patch to do it.

So what happens to the 25% of our users who updated to 45.0 and now have and use the correspondants column, and now it is disabled behind a hidden preference?

(In reply to Kent James (:rkent) from comment #24) > So what happens to the 25% of our users who updated to 45.0 and now have and > use the correspondants column, and now it is disabled behind a hidden > preference? Nothing. This only affects the default column list (i.e. what you see when you open a folder you've never opened before), and turns off the upgrade that replaced From/Recipients with Correspondents. If you have a folder with Correspondents already, it will stay the same. If you're on 45.1 and want to use Correspondents, you can enable that in the column selector as with any other column.

(In reply to Jim Porter from comment 25) In reply to Kent James, you posted: "Nothing. This only affects the default column list (i.e. what you see when you open a folder you've never opened before), and turns off the upgrade that replaced From/Recipients with Correspondents. If you have a folder with Correspondents already, it will stay the same. If you're on 45.1 and want to use Correspondents, you can enable that in the column selector as with any other column." Jim, I'm the new guy here. I'm not familiar with the TB process for fixes and for creating new code. However, I am very familiar with both UI/UX and also with communications with users in general. From what I see here, it appears that the decision has been made to roll the TB45 'upgrade' using 'Recipients' back out in some form, and to revise further upgrades for users to include some sort of selection device to allow users to use or not use the 'Correspondents' feature. If I am correct in this, that's great. Just make sure of two things: - No change is installed without the user specifying that they *want* it. - The choice is presented to users *before* the upgrade to TB45 (and future versions, including 45.1) is installed. Now, to another problem. In your quoted comment, you state "If you have a folder with Correspondents already, it will stay the same." I do not believe that is an acceptable resolution. Any such patch to TB45.1 *MUST* include a capability to entirely roll the implementation of the 'upgrade' to 'Correspondent' back to 'From' and 'Recipient' for anyone who does not want to use the 'Correspondents' scheme for whatever reason. - The use of 'Correspondents' must be a choice, and it should be NOT the default. - All folders have the previous system of 'From' and 'Recipient' active, and THAT IS the default. As I noted earlier, I have tens of thousands of e-mails in my history folders, and I do have to go back and scan them periodically to recover information. I do *NOT* want to continue to be plagued by this issue of someone who likes the single column concept having forced their preference upon me. Also, I really resent the cavalier attitude of some that "Oh, well, those who don't like it can just spend hours, days, even weeks, of their precious time going back and reverting the folders on a folder-by-folder basis." In my *very* humble opinion, that simply is an unacceptable attitude. Some of the people who are commenting here do not seem to get it. You were entirely correct that this 'upgrade' has caused an apparent loss of data and function, one that only can be corrected on a folder-by-folder basis and with very detailed understanding and many steps. The overly-aggressive TB45 rollout created this mess. A bug report was filed on it. It needs to be fixed, entirely and properly, not bandaged with mud. Users who already have unknowingly downloaded and installed the TB45 upgrade deserve the opportunity and a simple, easy-to-use method to back out of the "Correspondents" portion of that upgrade and revert *all* folders to their original presentation if they wish to do so. Anything less is a presumption that somehow not having presented, by default, information we want and use is OK. It is not. And for many of us, it is *not more convenient or desirable* to have less information. Please see that this gets fixed properly. Regards - John Fairbairn

(In reply to John from comment #26) > Now, to another problem. In your quoted comment, you state "If you have a > folder with Correspondents already, it will stay the same." I do not > believe that is an acceptable resolution. Any such patch to TB45.1 *MUST* > include a capability to entirely roll the implementation of the 'upgrade' to > 'Correspondent' back to 'From' and 'Recipient' for anyone who does not want > to use the 'Correspondents' scheme for whatever reason. Unfortunately, it's impossible to roll this back in general. The best we could do is to make a guess what the user wants, but that guess is guaranteed to be wrong for some users. If, in 38, a user had the From and Recipients columns shown together in a folder, both are removed and replaced with Correspondents. After the fact, there's no way to tell if the user had both columns or just one. I'd argue that trying to roll back would actually make things *worse* for the group of users I'm most concerned about helping out (the ones who originally had both From and Recipients enabled in a single folder). Because of that, I must refuse to automate any kind of rollback of user prefs. We simply don't have enough information to do so properly.

I should also reiterate that only the folders a user *opened* after upgrading to 45.0 will be affected. If you didn't open the folder, it's still fine, and once you get 45.1*, you'll be able to safely open it, and nothing will happen to your column layout. As comment 4 notes, updates to 45.0 have been disabled, so no new users will receive the update until we either turn it back on (unlikely) or release 45.1 (more likely). Since 45.1 corresponds to Firefox 46, which was released this Tuesday, I expect 45.1 to arrive very soon. * Assuming this patch is shipped with 45.1, of course.

To expand on that a bit: It appears that if your account was set up for "from" and "recipient" And The account was previously expanded (that is not collapsed and shoeing "drafts" "sent" "trash" etc. The inboxes are _not_ affected by the correspondents upgrade Other folders within the hierarchy are, when opened, but at least not the inboxes. This lessens the severity of the bug IMO

In reply to Jim Porter (:squib) at comment 25 You stated in a reply to me that "Unfortunately, it's impossible to roll this back in general." OK. Granted and accepted. And I do understand the reasoning for not doing a general rollback, unless you somehow could capture the exact sequence that was used to make the change (including recovering what columns previously had been selected by the user in a history, which *should* have been made as part of the update process) and then reverse that process to re-establish exactly what the user originally had. By the way, this begs the question, is creating a history of the user's initial setup in an area that is to be updated a part of *all* upgrades and updates? If not, why not? It should be, just for the very reason presented by this present situation. Now, what to do about this? How about this? Create a tool that allows the user to specify (for the main listing page and all selected folders) what columns the user wants to have shown. When the user presses 'CHANGE', the page is reconfigured to the requested set. That way, if a user wants to revert all folders, they can, or they can select several folders and run one configuration, then select another set and run a different one. It would be a useful tool to have anyway. That would allow users to reconfigure easily, far more so than having to open each folder individually and reconfigure it manually. I would find such a tool acceptable for the present situation, and I suspect that a majority of other users would as well although I will let them speak for themselves. In other words, please, throw us a bone to assist in recovering. Thanks for considering, and Jim, I particularly appreciate your patience. I can be somewhat of a gadfly at times, and somewhat prickly, and I don't mean to alienate anyone. I just want my formats back, but can not accept that I may have to spend days or weeks accomplishing that. I do know that I opened more than 50 folders using a bulk search before I discovered the change. All of them have been modified. And I can not seem to set the my system to stop modifying the folders. Regards - John Fairbairn

(In reply to John from comment #30) > By the way, this begs the question, is creating a history of the user's > initial setup in an area that is to be updated a part of *all* upgrades and > updates? If not, why not? It should be, just for the very reason presented > by this present situation. The way we used to handle upgrades is that we had a "Migration Wizard" that would run automatically after an update and give users the ability to pick and choose what new features they'd like, along with an explanation of why we think the new way is better. We got rid of that unfortunately, since we'd had a long period where it was totally unused (we had no features that required migration). I'm trying to bring it back for situations like this. The Migration Wizard would require the user to confirm whether they want the new behavior, so as long as they read the description in the wizard, they should know what's what. In that case, we wouldn't need to keep a history of the user's settings, since we wouldn't be changing them automatically. > Now, what to do about this? How about this? Create a tool that allows the > user to specify (for the main listing page and all selected folders) what > columns the user wants to have shown. When the user presses 'CHANGE', the > page is reconfigured to the requested set. That way, if a user wants to > revert all folders, they can, or they can select several folders and run one > configuration, then select another set and run a different one. It would be > a useful tool to have anyway. We actually have something very similar to this. One you change the columns in a single folder, you can open up the column list again (that little thing at the right end of the column names) and go down to "Apply Columns To...". Then you can pick "Folder and Its Children" and apply your settings to a whole account all at once. However, I'd also like to add the ability to do this for *all* accounts in a single step, and possibly to set the default columns for newly-created folders as well. These are fairly minor, all things considered, but they would make it easier for users to set up their columns according to their preferences. Another thing I'd like to do is to add some logic so that, if you have the "From" column in an *incoming* folder and you say "Apply Columns To..." a whole account, it should be smart enough to replace "From" with "Recipients" for *outgoing* folders (e.g. Sent, Drafts). > I do know that I opened more than 50 folders using a bulk search before > I discovered the change. All of them have been modified. And I can not > seem to set the my system to stop modifying the folders. If you're still having issues with folders being modified, see comment 1 on this bug. Or just do this (I'm just rephrasing the relevant part of comment 1): First, go to Tools (or the three-lines icon in the top right) > Options > Advanced > General > Config Editor. It may say something like "This will void your warranty!" Just click through that, and you'll get a table of config options. Type in "mailnews.ui.upgrade.correspondents" in the text box, and you should see a single result in the table with a value of "true". Double-click it to set it to "false". That will prevent the "upgrade" process from running, and your folders will remain unchanged.

(In reply to John from comment #30) and (In CC: reply to Jim Porter (:squib) from comment #31) John, As another mere user of Thunderbird, but one who also has some decades of experience with user interfaces in a variety of systems, let me reinforce Jim Porter's concise rephrasing of the steps I offered in in the other bug report and that he copied to the top of this thread. If you do set the "mailnews.ui.upgrade.correspondents" preference to false in your TB client, that will prevent any further replacement of the From and Recipients columns by the new Correspondents column in folders you have not yet visited since the 45.0 upgrade. For the folders that have already been converted, you do not have "to open each folder individually and reconfigure it manually". You can just reconfigure one folder and than use the "Apply columns to..." option under the "Select columns to display" icon that I previously described to apply that folder's reconfiguration to any or all other folders in your client. Best Regards, Vincent Prichard

(In CC: reply to Jim Porter (:squib) from comment #31) and (In reply to UpperBear from comment #32) Jim, it sounds like that Migration Wizard might work well for a lot of purposes. Please, I beg you, push the development and get it made available for use again. I hope never to see any migration forced upon a user again. And thanks for your patient guidance. Vincent, thanks so much for both your concern and your kind rewording. I tried what you suggested and discovered some things about TB that I never knew ... such as that there were columns of information about messages that I did not know existed. Up to now, I had thought that WYSIWYG. Thanks! I am not sure, but I think that in the main I have most of the damage corrected now. At least, I have the 'upgrade' downgraded so it is not forcing the 'Correspondent' change any more. And now I do know how to modify the column settings in any folder (and its children) that I do open which has that 'Correspondent' feature included. Again, kudos for your much-more-clear description. Just for information, gentlemen, migrating a set of settings from a folder to its children is not all that intuitive. As you go down the set of selections (Select columns to display > Apply columns to > Folder and its children > [account name], it is not intuitive that you have to bink on the [account name] to open a dialogue that includes 'Apply'. That was why I could not get the settings to take on the child folders. As a suggestion, it might be desirable to change the sequence so that hovering the cursor over an [account name] (rather than the action of selecting it) opens the dialogue (similar to the behavior of the rest of the selection sequence) so a user can see that they must apply the settings for that account (and its children, if appropriate). Warm regards - John Fairbairn

(In reply to Jim Porter (:squib) from comment #31) Jim, another minor note: It has taken me to now to discover that tiny little icon that allows a user to open the 'Select columns to display' sequence. I have been using TB for years and never stumbled upon it before. It is so small and unclear that it seems like there is nothing there. I know real estate in displays is precious, but is there some way to make that particular icon more visible, and thus more likely to be discovered and its features used? Warm regards - John

(In reply to John from comment #33) > (In CC: reply to Jim Porter (:squib) from comment #31) and > (In reply to UpperBear from comment #32) > > I hope never to see any migration forced upon a user again. I hope so, too. Thank you for your work on this. Unfortunately, I wasn't able to undo the damage by applying changes to groups of folders, because I don't use the same columns in each folder. Forcing changes on users, especially micromanagement changes like this, is bad because the programmers simply don't know what we are doing here with the program, so they can't reliably guess what's best for us. Thank you again, Jim

(looks like I supplied the final patches, so I'm taking the bug.)

Aurora (TB 48): https://hg.mozilla.org/releases/comm-aurora/rev/168a3e6360df

(In reply to Jim Porter (:squib) from comment #28) > As comment 4 notes, updates to 45.0 have been disabled, so no new users will > receive the update until we either turn it back on (unlikely) or release > 45.1 (more likely). Just to point out that updates on the Release channel have NOT been disabled, or hadn't been this morning around 10.00 GMT 30/04/2916 when it happened to me.

My comment is slightly off. We disabled AUTOMATIC updates. Manual updates are still enabled. Based on that, you must have done "check for updates".

> Jim, another minor note: It has taken me to now to discover that tiny > little icon that allows a user to open the 'Select columns to display' > sequence. I have been using TB for years and never stumbled upon it before. > It is so small and unclear that it seems like there is nothing there. I > know real estate in displays is precious, but is there some way to make that > particular icon more visible, and thus more likely to be discovered and its > features used? > > Warm regards - > > John Just a related note: The list of available columns is also displayed when one right-clicks on any column's header. (Right-clicking is a Windows-and-perhaps-other-OS action, and regrettably, I can't tell you if there is an equivalent that does this same thing in Thunderbird's versions for Apple's OS's or others. Long-press, maybe?) I'm not telling you that this served you better, John, since you didn't know that either. I'm just informing anyone reading this that it's another way to find the same thing, and without looking for the tiny icon at the right end of the column headers. As an experienced Windows user who intentionally fiddles with details and looks for ways to customize and control things, I found this "right-clicking on column headers" functionality long ago, without noticing the right-end icon until I decided to see what it represented or did. That seemed so natural & common for Windows that I pretty much forgot about the right-end icon; it *may* be easier for others to remember as well. In any case, it's another existing option. *Could* it have been integrated into the main menu items? I suppose so; but it hasn't been, that I can discover. Different related note: A Tooltip pops up *if* you happen to hover the mouse over that right-end icon as well, a Tooltip reading, "Select columns to display". I think that this is, as it stands, one of those features that is there to be discovered, either by exploration (directed or random), or by searching for the answer to questions like, "Can I (or how do I) show more information about my e-mail in the main e-mail list pane?" (For better or for worse. While I admit that to *me*, choosing columns of information from a list is one of those essential features that I would always look for, and know to look for, when using any of a number of types of software ... I readily concede that there are others different education, experiences, and expectations.) Now that you know of this sort of feature in Thunderbird, I can tell you it's worth looking for in lots of other programs, like file explorers, e-mail clients, and many more that show columns of different pieces and types of information.

FOR PEOPLE LOOKING TO ROLL BACK, IN THE FUTURE: This won't help anybody wishing to roll back right now, if they weren't already doing what I'm about to describe. But it could be used to help those people in the future, if they again wish to roll back some other future version(s). And it describes a Thunderbird version with other advantages. <http://portableapps.com> They offer "portable versions* of a variety of *free, open-source* software programs -- mostly, but not only, for Windows -- from various sources. Including Thunderbird. Generally whatever the most current version is (with some possible lag between release and prep as a portable version), and sometimes slightly older versions are still available somewhere on their website or elsewhere. What is a "portable" version of software? A longer answer is at <http://portableapps.com/about/what_is_a_portable_app>. Here's a shorter answer in bullet points: --- * the same program as the original, still free, still open-source * packaged so that you don't have to install it (in the usual sense of "install", including installation permissions, multiple directories, permanent registry entries, etc.) * can be run from a fixed hard drive or any portable media (SD card, hard drive, flash, ...) * carry it to any computer, which automatically handles things like changing drive letters * exists entirely in one directory (& sub-directories of that) * copy/move/delete the program and everything about it simply by doing that to its directory * keeps settings, history, work stored saved under the program directory, etc., wherever you carry it * updates using the program's own update procedures, and updates stay with it, too! --- So, I use "Portable Thunderbird" on my laptop. During my ongoing usage, I don't notice any differences -- it's Thunderbird. I ***NEVER*** accept automatic upgrades/updates. (For anything!) I do accept automatic notifications that upgrades/updates are available, and accept responsibility for dealing with them. Before performing any version upgrade, and before anything else potentially destructive, and sometimes more often, I do two things: A) do a fresh check for any and all new mail in all e-mail accounts used with Thunderbird, B) finish dealing with all of it as much as I possibly can, and then LASTLY, C) empty a directory that I named "ThunderbirdPortable - BACKUP BEFORE VERSION CHANGE" and then copy the contents of my entire "ThunderbirdPortable" directory into it. I thus have an entire, and entirely separate, running copy of my "program, mail, settings, EVERYTHING" saved. Note that all I had to do was make a copy of my program directory, simple! Then I do the version upgrade, AND DO NOT ENTER PASSWORDS OR DOWNLOAD MAIL when I open the new version. CAUTIONARY NOTE: If you have any of your accounts automatically log in and download mail when you start the program -- not necessarily unreasonable -- you might want to prevent this on version upgrades if you want to be cautious. IMAP users might want to take some sort of similar precaution, since you don't precisely work on local copies of mail. This is so that if I notice or learn about anything that I consider undesirable ("See? Subjective and non-confrontational, but accurate."), I won't risk damaging or losing any new mail. To be repetitive and clear, without downloading any new mail, I check out the new version, including the "What's New?" notes that appear *after* the new version is installed. I DON'T GET NEW MAIL UNTIL I'M REASONABLY SATISFIED THAT THINKS LOOK OKAY ENOUGH TO ME, TO RISK IT. Once I download new mail, I might yet find undesirable things that affect my e-mail letters, but because I have a backup of as much of my mail as possible, with as much of my work with it done as possible, the most I risk (at least with my POP3 accounts) is losing whatever mail downloaded *since* the upgrade and having to re-delete anything I deleted, maybe having to copy or re-create some amount of my work. How much this is will vary with the amount of time passed between upgrading and discovering a problem, AND how much mail is downloaded and how much work is done between upgrading and discovering a problem. If I find that I want to go back to the earlier version for any reason, I only have to: --- * take steps to preserve any new mail and/or work done, if I want to * delete the contents of "ThunderbirdPortable", and copy the contents of "ThunderbirdPortable - BACKUP BEFORE VERSION CHANGE" into it -- copy, don't just rename -- KEEP your backup! Just in case! --- That's it. It's just that simple. I make a point of wiping the entire folder's contents, so that I KNOW that I'm not dealing with problems from anything new or changed being left behind and not-overwritten. It's safer. I'll be dealing with the program and contents exactly as it was at the moment I backed it up, including probably getting a notification that I could upgrade again. If I saved copies of any new mail downloaded or generated by me, I can try to integrate that back into my brand new "old copy" of Thunderbird. [I LEAVE HOW TO DO THAT SORT OF THING TO YOU TO RESEARCH, BECAUSE I CAN'T ANTICIPATE EVERYTHING YOU MIGHT HAVE DONE OR NOT DONE.] *Hopefully*, you have lost very little mail or work, or even none at all. But at least you have ditched whatever problem you found in the new version, whether it was something big or small, whether it was something in Thunderbird itself or something related to an add-in or something else. You're back to your pre-upgrade version with all of your e-mail and work as of the moment of backup. At that point, it's up to you how to proceed further. Sometimes, I have tried the upgrade multiple times, with or without final success in the upgrading, but always able to restore. [Side-Note: This isn't a thing about PortableThunderbird, but is a thing about how I tried to use my backups in a particular kind of upgrading situation. A few times, I have had Thunderbird download the upgrade version, restarted, then seen a pop-up dialog telling me that there was some problem with the upgrade. I'm a bit fuzzy on the details at this point. It was a pretty plain pop-up. I then had the option to "do the upgrade manually", I think, or "download the installation files manually", something like that; and fortunately, that "manual" operation involved only clicking a button in the same little dialog window. Sometimes, I cancelled out of that and restored my backup to try the normal way again, even multiple times, but -- since all the files were starting the process in the same state each time, and I guess it wasn't a network problem that got corrected in that short time -- I got the same results until finally "accepting my fate" and clicking the button to do things manually. However, that seems to have worked out, because I don't recall noticing any problems after upgrading that way, wary as I was.] -- Pootmonkey P.S. I hope that the above is all complete and correct. If you notice any problems, please do let us know. I don't see a way to edit or delete after posting, but later corrections or other updates will still be good. And for what it's worth, I give permission to share any of this post anywhere you want, for commercial or non-commercial purposes. Call it a gift. Please just don't call my work somebody else's, for the sake of honesty and accuracy :) . For that matter, don't call someone else's work mine -- who needs the responsibility :) ?

While the feature change was not a bug, the result was clearly displeasing to many as it was not clear what happened. It's also still not clear why those arrows exist as they seem to serve no purpose and no one has been able to explain a useless icon on every email. The actual bug is that this change only affected about 50% of folders, and not even in any consistent parent/ child way. You had to go through every folder to see what it was displaying and make changes as needed. So two things Mozilla needs to do. 1. Determine why the process was so random, and 2. Explain and disclose such things on upgrade. Where was the popup to notify that this change took place and what it's for?

Comment on attachment 8746704 [details] [diff] [review] Hide correspondents behind a preference and remove the upgrade code (v3) - ESR45 only http://hg.mozilla.org/releases/comm-esr45/rev/0d1274dffb75

In the comm-esr45 builds when this was landed, large number of mozmill tests started failing. Please investigate these failures and comment on the validity of these failures.

Jorgk, can you please investigate the mozmill failures on comm-esr45 that occurred after we landed the patch there, and comment whether these can be safely ignored for the build of 45.1.0 If so, we will really need a followup bug to fix these failures, as otherwise we will be seeing them throughout the TB 45 cycle.

Maybe https://hg.mozilla.org/releases/comm-esr45/rev/0d1274dffb75cadc88320ebbac7fedcd3492fa04#l1.13 Trunk and Aurora got landed with the preference set to "true" and show no test failures. You can decide whether to pull out the patch or ship with "true".

Follow up: bug 1271108.

Looking at the comments in bug 1271108, the issue we are seeing in esr45 is due to a test that makes now false assumptions, and not due to a real problem that should concern us. So I see no reason to hold TB 45.1.0 because of these tests failures, or to backout this patch for that release.

Comment on attachment 8746703 [details] [diff] [review] Hide correspondents behind a preference and remove the upgrade code (v3) http://hg.mozilla.org/releases/comm-beta/rev/93e4725bc203

(In reply to Jim Porter (:squib) from comment #2) > For those coming here wondering how to fix their columns' settings, please > read the following (from bug 1152706): > > (In reply to UpperBear from comment #53) > > Do not despair -- I, too, was appalled to find all my dozens of folders > > switched automatically to the Correspondents column in lieu of the From and > > Recipients columns after the 45.0 upgrade. But the change can be backed out > > (and made to stay out) by these steps that worked for me: > > > > 1. Use the Config Editor to create a new preference named > > mailnews.ui.upgrade.correspondents and set it to false. This will prevent > > the change from happening automatically in the future. Here's the path to > > do that: > > Tools > Options > Advanced > General > Config Editor > > Click past any warning message about using the Config Editor. > > Right-click anywhere below the headings of the "about:config" dialog and > > choose New, then String. > > Type mailnews.ui.upgrade.correspondents for the preference name and click OK. > > Type false for the string value and click OK. > > Verify that the new preference was set and close the "about:config" dialog. > > > > 2. Set one folder in the Local Folders tree to the desired column selections > > and spacing via the "Select columns to display" icon at the far right of > > column headings bar. > > > > 3. Use "Apply columns to..." under the "Select columns to display" icon to > > copy the selections of the current folder to all other folders and children. > > Here's the path: > > Apply columns to... > Folder and its children > Local Folders > Local > > Folders > > Click on the *second* "Local Folders" and then OK in the "Apply changes?" > > dialog. > > > > You will need to repeat steps 2 and 3 for any other folder trees you have > > besides Local Folders. I've just discovered an annoying lingering effect of the forced Correspondents column upgrade that is not fixed by the procedure outline above. If I choose "Search Messages" for any folder, even one that does not have the Correspondents column active and does have the From and Recipients columns active, the new "Search Messages" window shows the Correspondents column but not the From and Recipients columns unless I manually select them. The same behavior appears each time I open the "Search Messages" window, even if I have altered the column selections during a previous search. How can I get the "Search Messages" window to always display the the From and Recipients columns instead of the Correspondents column?

For the search, this was fixed in bug 1277844. As per bug 1277844 comment #10, this will ship in TB 45.3.

Thanks Jorg -- sorry I didn't find the previous bug on this matter.