This is a carry-over from bug 36489. > IMHO, we should force a UI change onto the user. I think the "upgrade" to the new scheme is just a little to aggressive: https://dxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#693 What's wrong with leaving it turned off by default? Also worth noting: Compatibility issues with previous versions caused by aggressive upgrade: Bug 36489 comment #158. Sorting by the new column: Bug 36489 comment #159.

By storing the column states in a new property we don't confuse older versions. The code to retrieve the column states checks both properties of course.

I'm still questioning the decision of the "upgrade". When the user switches to TB 39+, they will automatically get the new column, right? Is it desired to shock the user or to give them a new feature they can select if they wish? Personally, I'd prefer the latter. If I read the patch correctly, a new property to store the column states is used. So basically TB38 and TB39 operate on independent column states. That still doesn't help the users who don't want the new feature and have to switch it off in every single folder they visit.

Comment on attachment 8590457 [details] [diff] [review] Why do we need more than to remove the aggressive upgrade? Bug 36489 comment 111 seems to make it quite clear that (except in news folders) the new column should be the default where possible, otherwise people will never discover it. (But if you don't want it to be default, you would remove the whole upgrade block and its comment.)

Bug 36489 had become so long that I didn't see this comment ;-) I think implementing this new feature which people wanted for 15 years (!!) is great. On the other hand I don't think it's a good idea to "force" it upon people who've been working without it for 15 years. Yes, the visibility of the feature is a problem. But that's what release notes are for. You put in a prominent place that you can now combine "From/To" into one columns with a screenshot. Those you care will find it. And also, it's the default for new users and those you reset the columns to the default. Isn't this enough visibility? The new "expanded columns" (bug 464973) arrived very subtly, and how hard do you have to look to find the "maildir" feature which is new in TB 38. I'd just like to avoid feedback like the one given to Fierfox here: https://medium.com/@trog/forgetting-firefox-c04dba853263 "What random interface changes are they going to introduce?" Why don't we ask on tb-planning what people think?

> it's the default for new users and those who reset the columns to the default. And it's also the default for new folders, so one should hope that users will see it ;-)

Comment on attachment 8590457 [details] [diff] [review] Why do we need more than to remove the aggressive upgrade? I think we should stay with enabling it by default. As we know, like manuals, almost nobody reads them and nobody knows this column exists. For this we should promote this with enabling by default. What also could be possible is a dialog asking, when upgrading, if the new combined column should be used instead of the to/from columns. Then the user can directly decide if he wants it or not. If he doesn't want the column now he knows now it exists and can use it later.

Let's see what other opinions we get: https://mail.mozilla.org/pipermail/tb-planning/2015-April/003762.html A dialogue is more work and also confuses the user. They already know nothing about the update and don't want to answer niggly questions, especially at the point where they had no chance to check out the feature. As I said: New folders/users will get the new column, so it's pretty clear it exists ;-)

Another option would be a preference, so users who don't want the feature can switch it off instead of having to revert the auto-upgrade in every folder they visit.

Typo in previous patch, sorry.

My little survey on tb-planning sadly only had three people replying so far. Not counting myself, two were against a forced upgrade, the third one didn't mind as long as there was an option to disable the forced upgrade. Here is a proposed patch for such an option, a two-liner. I have no experience with naming preferences, so of course the name could be changed. Whether the default should be "true" or "false" is also subject to discussion. If set to true, the new feature would be immediately visible and all who don't want it, can switch it off later. Same as with Firefox' new searchbox (browser.search.showOneOffButtons).

Jorg, I'd like to see other people weigh in. I replied to your "survey" on tb-planning, but I don't think it's fair to claim that it is representative. You know as well as I do that whenever a new feature comes in, a handful of users are always going to complain that they experience they'd had for the past 20 years just changed. If we can't make new changes visible in the UI, then it's not worth implementing new features -- no one will ever use them. I think we're still far away from the kind of UI landslide changes that took place in Firefox, and even then, I've become pretty accustomed to them and I don't seem to regret anything from before. I, too, complained about the new searchbox, but after a few weeks of usage, I seem to be pretty happy with it. So being reticent to new features is not a universal thing :-).

(In reply to Jonathan Protzenko [:protz] from comment #12) > If we can't make new changes visible in the UI, then it's not worth > implementing new features -- no one will ever use them. I repeat: The change will be visible for new folders and therefore new users. Also the users who one day click on the column header will discover the new column. Anyway, I submitted a patch to implement a preference to do or not to do the auto-upgrade. We can have the preference set to "true" by default, then only the people who don't want the auto-upgrade part of the new feature can switch this part off. One other thing that came up in the discussion: Colour: It would be great to have the opportunity to colour the "Correspondents" entry. Or at least publish how it can be done in the userChrome.css Sorry for being so opposed to change ;-) It's not actually so. I'd just like to evaluate the new feature slowly instead of having it imposed on me.

(In reply to Jorg K (at the beach until 22nd April) from comment #13) > Sorry for being so opposed to change ;-) It's not actually so. I'd just like > to evaluate the new feature slowly instead of having it imposed on me. I'm not trying to be attacking at all when I say this, but... Could you name *one* project where *every possible change* is approved by the users? Claiming that we need to get all features "user-approved" is absurd, that just doesn't happen. You might claim that this feature is more noticeable than others, but I'd strongly disagree with that. I did say that I would like a pref to disable it, but after thinking about it, I'm not even sure about that. That's just more maintenance burden, and if you want to make this the standard, we'll end up with hundreds of these Ifs, which just isn't necessary. As for the post on tb-planning, a very small number of people have commented on that, and I would suppose that's because most really don't care that much, definitely not enough that they would fight for it. Besides, in the end it's either myself, Richard, or others from https://wiki.mozilla.org/Thunderbird:UX/Team that you need to convince.

If new features are not on by default for existing users, then there's little point in implementing them. The only thing that needs fixing here is to have a way to "Apply columns to > All folders" instead of the tedious "Folder and its children". That way, you'll have just a fix clicks needed to revert the change. I think that should be a separate bug.

Comment on attachment 8591029 [details] [diff] [review] Patch to control the upgrade via a preference As Josiah wrote, add this pref would be more maintenance burden. And if we would use this pref, then it should be on true. When a user don't want it at all, he can toggle it. I, for example, have since long time not added a new folder and thus not remarked this column would exist.

(In reply to Josiah Bruner [:JosiahOne] (needinfo! - Won't respond to CC)) from comment #14) > Besides, in the end it's either myself, Richard, or others from > https://wiki.mozilla.org/Thunderbird:UX/Team that you need to convince. I wasn't aware of the hierarchy. Since Richard mentioned a dialogue in comment #7, there would have to be a preference to store the answer. So perhaps you and Richard and any other powers that be can decide whether a preference is possible here or not. [Wires just crossed, Richard said "no" a preference that disables the upgrade]. I think we all agree that using the new column will be the default, the question is only what "default" means and whether changing the default automatically means upgrading all existing data while leaving no choice but to upgrade and later undo the update on a tedious folder-by-folder basis. (In reply to Jonathan Protzenko [:protz] from comment #15) > The only thing that needs fixing here is to have a way to "Apply columns > to > All folders" instead of the tedious "Folder and its children". Nice idea, except, it doesn't address all of the problem. The current upgrade replaces "From" and "Recipient" columns and there is not way to restore that on a global basis, since users might have displayed one or both columns on individual folders.

New attempt, this time with a preference that's set to "true", to the update will happen unless explicitly disabled. I think that's fair, even Firefox allows users to switch off the goodness of the new search box.

Comment on attachment 8591251 [details] [diff] [review] Patch to control the upgrade via a preference, this time with "true" f+ for the default enabled pref. But you still need a review and the reviewer can decide if this pref is desired or not.

Comment on attachment 8591251 [details] [diff] [review] Patch to control the upgrade via a preference, this time with "true" @Neil: Thank you for the patch in attachment 8590974 [details] [diff] [review]. IMHO it makes things too complicated to handle two sets of column states. I guess the few people who want to go back and forth between TB38 and TB39 can just set the preference to disable the automated upgrade - if this is finally approved. Can you please tell me whether you're happy with the name "mailnews.ui.upgrade.correspondents" and whether it's in the correct spot.

Comment on attachment 8590974 [details] [diff] [review] Possible patch Review of attachment 8590974 [details] [diff] [review]: ----------------------------------------------------------------- I think this is probably complicating it too much ::: mail/base/content/folderDisplay.js @@ +413,5 @@ > /** > * The property name we use to store the column states on the > * dbFolderInfo. > */ > + PERSISTED_COLUMN_PROPERTY_NAMES: ["columnStates2", "columnStates"], PERSISTED_COLUMN_PROPERTY_NAME is used elsewhere too...

I hope we can settle for an "opt-out" reference (only for the automated upgrade) as proposed in my patch. Richard Martin gave it a feedback+, so perhaps someone else from the UX group can give the go-ahead. The exact name of the preference still has to be decided.

Comment on attachment 8591251 [details] [diff] [review] Patch to control the upgrade via a preference, this time with "true" (In reply to Magnus Melin from comment #21) > I think this is probably complicating it too much Fair enough. You still get to review Jork K's approach. (I have no objection to it, but my tree has conflicting patches in that area, so I can't try it myself.) > PERSISTED_COLUMN_PROPERTY_NAME is used elsewhere too... (Sigh, why must tests annoy me so?)

As I said in comment #20: > Can you please tell me whether you're happy with the name > "mailnews.ui.upgrade.correspondents" and whether it's in the correct spot.

Comment on attachment 8591251 [details] [diff] [review] Patch to control the upgrade via a preference, this time with "true" Review of attachment 8591251 [details] [diff] [review]: ----------------------------------------------------------------- I guess the pref name is fine. This needs to be unbitrotted though

Can you explain what you mean: un-bit-rotted??

Re-apply your patch on trunk, address the application failures, refresh your patch and upload. Also, sure, the opt-out is fine. Thanks.

Carrying forward Richard Marti's feedback+. Adapted to changes in trunk (bit rot).

Comment on attachment 8595575 [details] [diff] [review] Patch to control the upgrade via a preference ("true") Review of attachment 8595575 [details] [diff] [review]: ----------------------------------------------------------------- LGTM, r=mkmelin. Sorry for the delay!

How would that get checked in? In M-C, I'd just set keywords=checkin-needed.

yes it's the same for comm-central

Fixed -> https://hg.mozilla.org/comm-central/rev/0cd4ed416369

"Correspondents" is a string 15 characters long, too long for the column I have setup. This might be too long for other users. Unless you want a stream of new bug reports about this, do not force this onto users. Instead, make it an option.

(In reply to David E. Ross from comment #33) > "Correspondents" is a string 15 characters long, too long for the column I > have setup. This might be too long for other users. Unless you want a > stream of new bug reports about this, do not force this onto users. > Instead, make it an option. Oops! Sorry, but I did not see that this was fixed before I commented.

> "Correspondents" is a string 15 characters long, too long for the column I have setup. You can make columns smaller than their label. I just tried it and it works fine. (And the names of most people and From labels are longer than this word)

The release notes state: 'Add a Correspondents column combining Sender and Recipient.' downloaded version 45 from http://ftp.mozilla.org/pub/thunderbird/releases/ as it not available on release channel nor via main website. Using Windows Vista OS. Result: FROM column is auto not displaying and so has to be manually enforced. Not impressed. FROM is essential not a 'only if you want it' option and should never be disabled by default with the exception of the 'Sent' folder where 'Recipients' should be enabled by default. In the 'Sent' folder, 'Correspondents' is exactly the same as 'Recipients' with the exception that a grey arrow pointing to right - not sure what that is supposed to mean. It only displays all contact names who received an email from me = 'Recipients' column. In all other folders, 'Correspondents' column is exactly the same as the 'FROM' column with the exception that a grey arrow pointing to left - not sure what that is supposed to mean, but if I send an email to myself, then it will appear to point to the right - opposite direction, so I'm assuming the left and right indicated whether I sent the email or not....somehow I think I might notice that. It only displays the contact name of person who sent an email to me = 'FROM' column. I fail to see why so much time and effort was employed in duplicating something that already existed. The only difference is that it is enabled by default and FROM is not selected as a default column header - this needs recifying asap - since when has the FROM not been of utmost importance! It most certainly does not combine sender and recipient in any folder. In the 'Sent' folder it is not even required...there would only be me sending, so no point. Please remove the 'Correspondents' column header from default and replace with 'FROM' or 'RECIPIENTS' as appropriate. Explain why you have to duplicate the 'Recipient' column ?

I see lots of discussion here about "whether" the new Correspondents column should be forced upon all users during upgrade to 45.0 and suggestions that there should be a way to switch it off, but I don't see any information about how to revert to a user's previous preferences short of visiting each folder and manually resetting those preferences. When I upgraded to 45.0 today, all of my several dozen folders on three computers got the new column blasted in without any warning, and I am not happy at all about that. Maybe I've missed some instruction here, as the status shows "RESOLVED FIXED". Is there in fact a way get my previous preferences (which varied from folder to folder) back or not? Or will I have to restore the previous TB version from a backup? If I do that, will there be any way to avoid having the Correspondents column forced in again during a new update to the 45.0 version? Please help!

Well, I do see the attachment listed here, titled "Patch to control the upgrade via a preference ("true")", but I have no idea about how to install it or even whether it is intended to be installed by a mere user such as I. Can I some how apply that patch to the 45.0 version and then be able to restore the column preferences I had before upgrading to the 45.0 version?

I found how get all my folders back to one uniform selection of columns after the 45.0 upgrade: 1. Set one folder to the desired column selections and spacing via the "Select columns to display" icon at the far right of column headings bar. 2. 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 or to selected folders and children. But I still have a peeve about the following description of the new Correspondents column in the "New in Thunderbird 45.0" message: "The headings in the message pane now show a 'Correspondents' column by default instead of the 'From' and 'Recipient' columns. Existing folders will be upgraded to the new column, unless this upgrade is *switched off*." (asterisks added) The link under the *switched off* portion of that message goes to this Bug 1152706 thread, implying that there is a way to switch off the forced conversion to use of the Correspondents column and that it is described here. But I still see no such instruction in this thread.

Tools > Options, Advanced, General, Config Editor: mailnews.ui.upgrade.correspondents set to false.

Thanks a lot, but difficult to find in the German options. Here they are: Extras->Einstellungen->Allgemein->Konfiguration bearbeiten Though it did not work for all the folders I already visited before I changed it back. Quite a lot folders were damaged already. So is there a way to avoid this corruption? This really was one of the most annoying changes I ever had in thunderbird! (Though I was already used in regularly loosing the "from" column in a lot of your updates) How can you try to put two columns (from AND recipient) in one?!? In German "von" and "Empfänger" - both columns are very useful to me together. And why did you add this strange arrow?

I didn't design this feature. As far as I know, it was designed to allow people to view sender and recipient in one column much like some smartphone apps or some web interfaces. For details you'd have to study bug 36489. There was also a discussion in TB planning about this feature: https://mail.mozilla.org/pipermail/tb-planning/2015-April/003762.html (As you can see, I wasn't in favour of forcing this upon our users.) Correspondents ============== <=== Mickey (this is a message from Mickey) ===> Donald (this is a message to Donald). The preference mailnews.ui.upgrade.correspondents needs to be set *before* visiting the folders since it avoids the undesired upgrade to the new column. New folders will always be created with the new column, but there are various ways to change the columns back to "To" and "From".

johannes Falk: see comment 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1265446 "The Correspondents field works like this: * Same as "From" for received messages * Same as "Recipients" for sent messages That is, you can use Correspondents for all folders (incoming and outgoing), and they should show the same thing as before. The one exception to this is that messages from you in an incoming folder (e.g. a message you sent to a mailing list that came back to you) will show the recipients now; it used to show the sender (i.e. you)." So in addition to mailing listss showing better information, it is very useful if you use gmails 'All Mail' folder and do not like to use any sort method. It is also useful if you have selected to include eg: Replies in the same folder as the original. The direction if the arrows indicates whether the email was from you or you were a recipient. So if you usually keep sent in 'Sent' folder and receive incoming into 'Inbox' then you will see very little point and see exactly the same info as seen in FROM and SENT. I personally think most people use that method but the developers disagree, see comment 12 - https://bugzilla.mozilla.org/show_bug.cgi?id=1265446 "The upgrade code could definitely be improved, and there could be a way to roll back to *not* showing the correspondents column, but I think it's a perfectly sensible default in 99% of cases." therefore, I was asking for the 'Correspondents' column to not be auto set as default as most people have auto updates and therefore would be forced into the new default before knwoing it was about to happen and therefore see all their folders apparently messed up. As I put all eg: Sent in 'Sent' folder, I do not need an arrow telling me I sent it and taking up space. There is some code that can be used to display 'Correspondents' but without the arrow. This would need to put in a usrChrome.css file in a chrome folder in your Profle folder name. treechildren::-moz-tree-image(correspondentCol) { list-style-image: none !important; -moz-margin-start: -17px !important; }

If you have 'Correspondents' showing incoming and outgoing - I'm sure there are instances when this will occur as the developers think this is used by 99% of all cases....then how do you sort on the arrows to separate the FROM from the TO. I did request the arrows to be a separate column to faciliate this, but I do not feel it was thought to be important enough. How will it sort on correspondents listed when you want it to sort only the sender?

(In reply to Johannes Falk from comment #41) > it is difficult to find in the German options. Here is the button: not Extras->Einstellungen->Allgemein->Konfiguration bearbeiten but Extras->Einstellungen->Erweitert->Allgemein->Konfiguration bearbeiten sorry for any inconvenience.

> "The upgrade code could definitely be improved, and there could be a way to > roll back to *not* showing the correspondents column, but I think it's a > perfectly sensible default in 99% of cases." I guess I'm the grouch. I want the "old way". This is hiding information from me and requires on additional thought step to figure out what is happening (when my message returns). I immediately removed the Correspondents column and added From. But I have hundreds of folders and "Apply to folders and its children" doesn't seem to work. I AM SUNK!!!!!!! What can I do to get all the folders to show From and not Correspondents?

(In reply to Pete from comment #46) > I immediately removed the Correspondents column and added From. But I have > hundreds of folders and "Apply to folders and its children" doesn't seem to > work. I AM SUNK!!!!!!! Can you elaborate on how it doesn't work? It works fine for me. Please file a new bug though, since a resolved bug isn't a good place to track new work.

(In reply to Pete from comment #46) > > "The upgrade code could definitely be improved, and there could be a way to > > roll back to *not* showing the correspondents column, but I think it's a > > perfectly sensible default in 99% of cases." > > I guess I'm the grouch. I want the "old way". This is hiding information > from me and requires on additional thought step to figure out what is > happening (when my message returns). > > I immediately removed the Correspondents column and added From. But I have > hundreds of folders and "Apply to folders and its children" doesn't seem to > work. I AM SUNK!!!!!!! > What can I do to get all the folders to show From and not Correspondents? Pete, I am absolutely with you about wanting the "old way" -- the new Correspondents column is useless to me. I was appalled when it was blasted automatically into all my dozens of folders when I upgraded to the 45.0 version, and I firmly disagree with the comment (originally by Jim Porter, https://bugzilla.mozilla.org/show_bug.cgi?id=1265446#c12) that the Correspondents column is "... a perfectly sensible default in 99% of cases." Seeing actual names is much more intuitive to me, and I doubt that is the view of only 1% of users. In my view, new interface defaults should never be forced. Just tell people the new feature exists and let each person decide whether to use it or not. I'm not sure why the "Apply columns to..." function didn't work for you. The steps I mentioned in Comment 39 above did work for me. Did you follow the complete selection path, such as: Apply columns to... > Folder and its children > Local Folders > Local Folders [again and click here] When I click on the *second* "Local Folders", I get the "Apply changes?" dialog, letting me confirm application of "... the current folder's columns to Local Folders and its children". Clicking OK there makes my folder column selections identical across all folders and sub-folders.

(In reply to UpperBear from comment #48) > Seeing actual names is much more intuitive to me, and I doubt that is the > view of only 1% of users. Doesn't the Correspondents column show actual names? I'm not clear on what your issue is here. > In my view, new interface defaults should never be forced. Just tell people > the new feature exists and let each person decide whether to use it or not. If I had implemented the upgrade code, it probably would have been a little widget that says, "We've upgraded your thread pane to use the Correspondents column. Click here to roll back to your old settings." However, given that "Apply columns to..." works for you, it's pretty easy to reset everything yourself. In general, as long as it's easy to revert somehow, I'm ok with changing defaults as we implement new features. I don't think it's wise to force Thunderbird to be an unchanging legacy client. If we go down that path, we doom ourselves to eventual irrelevance, which is especially concerning given the increased centralization of modern messaging systems. I see Thunderbird as one of the better hopes for fighting against that trend.

(In reply to Jim Porter (:squib) from comment #49) > (In reply to UpperBear from comment #48) > > Seeing actual names is much more intuitive to me, and I doubt that is the > > view of only 1% of users. > > Doesn't the Correspondents column show actual names? I'm not clear on what > your issue is here. I like seeing *both* the sender name and the recipient name side-by-side, making it quicker for me to tell at a glance which is which. But maybe that's just me. . . > > > In my view, new interface defaults should never be forced. Just tell people > > the new feature exists and let each person decide whether to use it or not. > > If I had implemented the upgrade code, it probably would have been a little > widget that says, "We've upgraded your thread pane to use the Correspondents > column. Click here to roll back to your old settings." However, given that > "Apply columns to..." works for you, it's pretty easy to reset everything > yourself. > > In general, as long as it's easy to revert somehow, I'm ok with changing > defaults as we implement new features. I don't think it's wise to force > Thunderbird to be an unchanging legacy client. If we go down that path, we > doom ourselves to eventual irrelevance, which is especially concerning given > the increased centralization of modern messaging systems. I see Thunderbird > as one of the better hopes for fighting against that trend. As you can see from my initial comments on this thread, it was not easy for me to figure out how to revert from the unannounced changes to all my folders. I agree that feature evolution generally is a good thing. But I still think that an explicit announcement of this change, such as the one you would have offered, was essential for a change of this magnitude.

(In reply to UpperBear from comment #50) > (In reply to Jim Porter (:squib) from comment #49) > > (In reply to UpperBear from comment #48) > > > Seeing actual names is much more intuitive to me, and I doubt that is the > > > view of only 1% of users. > > > > Doesn't the Correspondents column show actual names? I'm not clear on what > > your issue is here. > > I like seeing *both* the sender name and the recipient name side-by-side, > making it quicker for me to tell at a glance which is which. But maybe > that's just me. . . This is one of the things that I didn't like about the upgrade code, based on my reading. The upgrade applied if you had From and/or Recipients columns in that folder; it should have been From exclusive-or Recipients. If a user has both of those columns, they probably don't want Correspondents.

Why on earth have you forced the Correspondents column without the option to place the columns back to my default? I don't want the Correspondants column at all. I have 5 different email addresses unified into one Inbox and now have no idea who the receipent is. In addition I have over 40 folders which will now require me to change each one individually back with Recipient and From columns and remove the Correspondents. If you had warned me prior to making this as a security update I would never have downloaded it. You have made this a very large step backwards and now I have to waste time reverting everything back to my setup. Is this going to overide my settings on every future update?

(In reply to elms2345 from comment #52) > Why on earth have you forced the Correspondents column without the option to > place the columns back to my default? > I don't want the Correspondants column at all. I have 5 different email > addresses unified into one Inbox and now have no idea who the receipent is. > In addition I have over 40 folders which will now require me to change each > one individually back with Recipient and From columns and remove the > Correspondents. > If you had warned me prior to making this as a security update I would never > have downloaded it. > You have made this a very large step backwards and now I have to waste time > reverting everything back to my setup. > Is this going to overide my settings on every future update? 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.

(In reply to Jim Porter (:squib) from comment #47) > (In reply to Pete from comment #46) > > I immediately removed the Correspondents column and added From. But I have > > hundreds of folders and "Apply to folders and its children" doesn't seem to > > work. I AM SUNK!!!!!!! > > Can you elaborate on how it doesn't work? It works fine for me. Please file > a new bug though, since a resolved bug isn't a good place to track new work. I may be doing something wrong but I don't have the time now to research it. I have two projects that are in crisis state and both require 24/7. What a time for this to happen. I can't win.

(In reply to UpperBear from comment #53) > (In reply to elms2345 from comment #52) > > Why on earth have you forced the Correspondents column without the option to > > place the columns back to my default? > > I don't want the Correspondants column at all. I have 5 different email > > addresses unified into one Inbox and now have no idea who the receipent is. > > In addition I have over 40 folders which will now require me to change each > > one individually back with Recipient and From columns and remove the > > Correspondents. > > If you had warned me prior to making this as a security update I would never > > have downloaded it. > > You have made this a very large step backwards and now I have to waste time > > reverting everything back to my setup. > > Is this going to overide my settings on every future update? > > 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. P.S.: In Step 1 that I mentioned, you may not have to create the mailnews.ui.upgrade.correspondents preference, as it may have been created by the 45.0 upgrade and set to true. So first search for it in the Config Editor and change the string value to false if the preference already exists.

(In reply to UpperBear from comment #53) > (In reply to elms2345 from comment #52) > > Why on earth have you forced the Correspondents column without the option to > > place the columns back to my default? > > I don't want the Correspondants column at all. I have 5 different email > > addresses unified into one Inbox and now have no idea who the receipent is. > > In addition I have over 40 folders which will now require me to change each > > one individually back with Recipient and From columns and remove the > > Correspondents. > > If you had warned me prior to making this as a security update I would never > > have downloaded it. > > You have made this a very large step backwards and now I have to waste time > > reverting everything back to my setup. > > Is this going to overide my settings on every future update? > > 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. No way do I have time to do all these steps even if they worked flawlessly. Maybe I don't have TB set up correctly but I have 22 email accounts. Each has all the typical sub-folders like Inbox, Sent, etc. Normally I use the Unified view. I don't even use Local Folders. It contains the hundreds of thousands of messages I imported from Outlook going back to year 2000.

(In reply to elms2345 from comment #52) > Why on earth have you forced the Correspondents column without the option to > place the columns back to my default? > I don't want the Correspondants column at all. I have 5 different email > addresses unified into one Inbox and now have no idea who the receipent is. > In addition I have over 40 folders which will now require me to change each > one individually back with Recipient and From columns and remove the > Correspondents. > If you had warned me prior to making this as a security update I would never > have downloaded it. After having this disaster happen to my home desktop computer I refused the upgrade to 45.0 on my work desktop and my tablet. I guess I am stuck at the previous versions on those machines.

(In reply to Pete from comment #57) > upgrade to 45.0 on my work desktop and my tablet. I guess I am stuck at the > previous versions on those machines. Just set the mailnews.ui.upgrade.correspondents pref to false and no upgrade will happen.

Yes, that works fine. I tried this on my second laptop. When TB 45.0 came up the first time, while in the 2nd tab, I set that pref to false and no upgrade to correspondents at all happened to any folder.

(In reply to Jorg K (GMT+2) from comment #40) > Tools > Options, Advanced, General, Config Editor: mailnews.ui.upgrade.correspondents set to false. (Also in comment 53, and quoted in 55 and 56) The above applies to people using the menu bar. For people using the application menu (3 horizontal lines at the right end of the mail toolbar), Options is not under Tools. The sequence is: Options, Options, Advanced, General, Config Editor: mailnews.ui.upgrade.correspondents, set to false. In greater detail: Click on application menu, hover over Options, click on Options, click on Advanced icon, click on General tab, click on Config Editor..., scroll down to mailnews.ui.upgrade.correspondents option (or find it using Search box), click anywhere on the line to change the option from true to false.

There are two major problems with the way that the "option to opt out of the forced upgrade" has been implemented. (I'm not here to bitch, but to help, so I'll even add, "unless there's something seriously different about my set-up :) .) For me, it was a good thing that I use the PortableApps version of TB, and always download all waiting mail then make a backup copy of the entire program folder before doing any upgrades. FIRST MAJOR PROBLEM: The Release Notes are displayed after upgrade, which is good. The "New in Thunderbird 45.0" Release Notes say this [I added pound-signs to indicate links.]...: --- [...] Message List and Message Header * The headings in the message pane now show a #"Correspondents" column# by default instead of the "From" and "Recipient" columns. Existing folders will be upgraded to the new column, unless this upgrade is #switched off#. [...] --- The first major problem is that this "switched off" link should point to a web page with clear and complete instructions for turning the option off *and nothing else*. It does not. It falls extremely short of good user service. The presence and labeling of the "switched off" link indicate it points to a place with ready instructions for turning it off. But it does not! It points to the *top* of this page, which is a long discussion (which has some -- incomplete, and useless if found after upgrade -- instructions *BURIED* in it). The discussion is also somewhat incomprehensible to the uninitiated; at least I'm a programmer myself, but many people who "just use e-mail" are not going to find this intelligible, and many are not likely to look far for or find what they were promised by the link. The beginning of the discussion on this page ... --- > IMHO, we should force a UI change onto the user. I think the "upgrade" to the new scheme is just a little to aggressive:[...] --- ... does not even begin to introduce the topic being discussed. It was a very confusing -- and, face it, unfortunately inhospitable -- landing-point for the link promising instructions for turning off the upgrade "forced on the users". Again, the link should go to A) working instructions B) without other stuff. SECOND MAJOR PROBLEM: I did find instructions here by at last skipping to the bottom in frustration -- wading through so many mentions of patches and review for ways to turn it off -- *hoping* to find whatever the final decision was. I still had to read a few more up from the bottom to get the right ones for my set-up. The second major failing is that the instructions *as written here* do not even work, and would also come too late if found after the upgrade has been done. (I assume it is typical and indeed most common for most users finding the Release Notes to find them because they have just completed the upgrade -- probably because that's how and when I find them. Do what you will with my assumption :) .) After various attempts, I discovered that the change in the Configuration Editor must be: --- A) made BEFORE the upgrade to have any effect (NOT mentioned here at all, in the last handful of comments, anyway) B) a new BOOLEAN value, not a string value of "false" as indicated here --- So instructions here are too late, incomplete, and incorrect. (As well as buried in all the discussion.) They seem to me to indicate that they will *reverse* the change already made, but perhaps that was merely my expectation. They do not do that, for sure! I don't know what your best avenue to fix this is. I'll leave that to you guys to figure out in detail, if you will. Will it involve another update that undoes the change followed by one that does what you tried to do here, better? You can't (read "absolutely should not") force the change on a user for the purpose of having them discover it, and NOT give them a path back from the change. Preventative medicine (the fix here) only works if you know you should take it ahead of time. -- Pootmonkey

I'm with Pootmonkey. Everyone uses their email platform differently, and you can't possibly know what is or isn't essential to all your users and make a decision to force a major change with no ability to opt out. Maximum choice and control of our own platform is essential. This change is messing up my system. too, and I hope it can be undone. I'm not a programmer, just a longtime user.

Bottom line. Is there a way to back out to a previous version?

Having just "upgraded" I have been hit by this - 60+ subfolders with "Correspondent" when From and To were just perfect. I'm afraid this is an example of fixing something that was never even remotely broken in any way whatsoever. "From" and "To" tells me exactly where I am: "Correspondents" and the arrow "thing" is plain confusing - and my apologies in advance to those who consider me "dense" as a result. No, I'm just way too old and I don't appreciate change when it's clearly not needed. So now I have to spend - sorry, waste - 30 minutes of my increasingly diminishing lifetime fixing this mess. Directing users to this thread for a solution just makes things worse - I could find no solution. I'm a big fan of Thunderbird but Mozilla has got this particular "upgrade" so wrong it's difficult to imagine how it could have made it worse; This is clearly a case of why use "to" letters when fourteen will do . . . .

Anybody know if this still works? http://kb.mozillazine.org/Go_back_to_an_old_version_of_Thunderbird Also, I seem to remember a recent upgrade before 45 that I refused because it was not compatible with the Lightening extension that I use. So I would need to know how far to go back. Thanks, Pete

This 'upgrade' is just horrible. I have tens of thousands of emails stored in hundreds of sub-folders going back more than 15 years. Depending on the nature of the work and / or people involved I sometimes store sent items in folders with received, and sometimes not. I'm always having to refer back to old discussions, and it's critical that I can navigate my way through conversations looking for what I said. Sorting messages using the old 'From' column made this process easy. The new arrows are a grossly inferior way, visually, of doing the same thing. It's been said above plenty of times, but forcing a change like this without giving users a one click place to revert is a really shoddy way to treat us. Yes, I know, it's free, so I don't have a right to complain (what, really...?), but right now YOU GUYS SUCK BIG TIME. There's no way I've got the time to waste going through and re-customising all my folders, so I'm going to look at downgrading to a previous version and then locking in to it. I love Thunderbird, but if you don't fix this, and fix it fast, I'll end up walking away.

I am absolutely with Comments 62-66. I foolishly accepted the "upgrade" and now it seems I only have two options: 1- revert back to an older version if possible or 2- find a new email program. I'm not a computer expert, I only use the email and this is a disaster for me. Someone please provide simple instructions on how to get out of this mess.

Please read comment 53 to see how to fix your columns.

To Jim Porter: I am not a programmer. I don't know what any of that means in the fix you referenced.

Can you elaborate? What part is unclear? The instructions look pretty detailed to me.

The most important thing is to change the preference as soon as possible to avoid further damage! Use the Config Editor and set mailnews.ui.upgrade.correspondents to false (proceed as mentioned above) DO NOT OPEN ANY FOLDER BEFORE YOU DID THAT! The damage happens only to those folders you look into. So, if you did not already look into a lot of folders, not much got "upgraded" (damaged). You only need to remove "correspondents" and add "from" and "to" in those few damaged folders - all the other folders remain unchanged (they were not yet upgraded). Even new folders will be created in the old style. Good luck!

A couple of hours ago I followed the instructions and changed the setting to "false". And there has been no changge to the column headings in my Inbox. What gives?

Did you follow all of the instructions in comment 53? In particular, steps 2 and 3.

@Dan There is no automatic revert or undo. The preference "false" only prevents further damage. You have to modify the "updated" folders manually. Open that folder and click on the rightmost position in the column header line to uncheck "correspondents" and check what column ever you like (e. g. "from" and "to"). You may use the last option to modify more than one folder. And if necessary, you can change the order of your columns easily as usual by moving them with the mouse (simply drag and drop).

@Dave "Having just 'upgraded' I have been hit by this - 60+ subfolders with 'Correspondent' when From and To were just perfect. I'm afraid this is an example of fixing something that was never even remotely broken in any way whatsoever. 'From' and 'To' tells me exactly where I am: 'Correspondents' and the arrow 'thing' is plain confusing ..." "I'm a big fan of Thunderbird but Mozilla has got this particular 'upgrade' so wrong it's difficult to imagine how it could have made it worse; This is clearly a case of why use 'to' letters when fourteen will do ..." I agree, 100%. @Piers "This 'upgrade' is just horrible. I have tens of thousands of emails stored in hundreds of sub-folders going back more than 15 years. Depending on the nature of the work and / or people involved I sometimes store sent items in folders with received, and sometimes not. I'm always having to refer back to old discussions, and it's critical that I can navigate my way through conversations looking for what I said. Sorting messages using the old 'From' column made this process easy. The new arrows are a grossly inferior way, visually, of doing the same thing. It's been said above plenty of times, but forcing a change like this without giving users a one click place to revert is a really shoddy way to treat us. Yes, I know, it's free, so I don't have a right to complain (what, really...?), <deleted>. There's no way I've got the time to waste going through and re-customising all my folders, so I'm going to look at downgrading to a previous version and then locking in to it. I love Thunderbird, but if you don't fix this, and fix it fast, I'll end up walking away." As a Senior Technical Communications Specialist, I must say that I am appalled by several items in this discussion. First and foremost, of course, is that Mozilla (via upgrade to Version 45) has forced users to accept a revision of their preferred method of displaying *their own information*, and has done so without prior notice before the upgrade was implemented. Then, @Piers mentions thousands of e-mails that now are displayed in a format he can not use and does not want, with only the choice of going through an extensive set of complex steps that are poorly enumerated for those of us who are not programmers or analysts. From a communications standpoint, the presumptions that those instructions are clear and understandable are enormously overestimated. I can not understand them or get them to work on my system, either, and I am trained in about 20 computer languages including Basic in all its flavors, COBOL, FORTRAN, C in all its flavors, Unix, and quite a number of others, as well as being able to read code in binary, octal, and hexadecimal formats. Please let me put this in context. I run a technical communications business. I have done so for more than forty years. Prior to that I was a biomedical electronics technician and prior to that I was a computer technician at Control Data Corp. In that time, I began using computers (and e-mail) about five years after the original DARPANET went live (c 1970). In the late 1980s I spent two years as one member in a team of eight communications specialists who read *every line* of the code in the Cray Research UniCOS Operating System, looking for security holes. I have records of every e-mail I ever have sent or received, using hundreds of different computers provided by my clients or employers, as well as over fifty of my own. Would you care to estimate how many tens of thousands of e-mails that represents? Or how many hundreds of folders are involved? Now every one of those folders has the extremely important *discrete* information about who wrote it and who received it thrown into one pot and scrambled like eggs, as a direct result of this upgrade. What could Mozilla possibly have been thinking, that this would be considered a 'good idea', 'desirable', 'necessary', or deserving of any such comment as "IMHO, we should force a UI change onto the user." Wrong. Absolutely, iron pyrite-plated, 100% wrong. Never, ever "force" a change upon a user. Especially, never ever mess with the user's data or its presentation in such a way that the user has no recourse for recovering. Dead wrong. @ Jim Porter, you asked "What part is unclear?" Well, in *my* humble opinion, everything about this 'upgrade'. Its reason, its manner of implementation, the lack of a clear-cut, pre-stated means of preventing the upgrade from affecting *my* data presentation, the lack of a simple, one-button recourse to 'un-do' the changes to the data presentation, *everything about this whole upgrade*! I have never seen the like of this fiasco, in all my years of involvement with electronics, technical communications, product design, implementation, interface design, and user service. Mozilla has a responsibility to its users to 'retract' this 'upgrade' by means of an immediate patch, and then to produce an upgrade version that gives the user an advance clear explanation of the "desirable" upgraded presentation and a choice, up front, to not accept that version of presentation. Mozilla also *must* provide in its Firefox software a means for users to designate which presentation they prefer, allowing them to switch between them at will. Anything less is a disservice to the user base and a disaster to some of us who must have direct access to the To and From data in discrete format for search and sort purposes. Mozilla created this mess. The status for this so-called bug is: NOT RESOLVED, NOT FIXED. Fix it. Properly. Now. Regards - John Fairbairn Rush Creek Research Company

OK, go it to work I think. I'll see over time. Nonetheless this was a terrible idea in it's implementation.

Since this bug is already marked RESOLVED, it's not a good place to track future work; things will just get lost. I've filed bug 1268325 to track removing the "upgrade" code entirely for now, at least until we come up with a better way to manage upgrades. Unfortunately, the way the upgrade code was implemented makes it impossible to fully-automated a rollback to the previous state (specifically if a user had both the "From" and "Recipients" columns enabled in a given folder), but it might be possible to write an add-on that gets 90% of the way there. In any case, please direct further discussion to bug 1268325.

@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 *this* bug discussion, not a new one. We need to insist that the problems generated by this fix be fixed under this bug report. Please cancel the new one, or revise it to point back here, 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". By the way, I also should have stated in my previous note here that I also have used more than two dozen completely different operating systems, and more than 200 different utility programs, including every implementation of DOS and Windows since DOS 1.2, and every implementation of Wordstar, Word Perfect, Word, Excel, and most of the rest of panoply of Microsoft products up to and including Publisher. I know good interfaces, and I have suffered through a number of terrible ones. 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 like ("IMHO, we should force a UI change onto the user.") 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 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

(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>.

Thank you UpperBear for the fix in Comment 53! I can confirm it fixed the Correspondents bug on my install. Now I have to keep everyone in the facility off of 45.0 until I can replicate this fix on a machine by machine basis.

(In reply to Kyle from comment #80) > Thank you UpperBear for the fix in Comment 53! I can confirm it fixed the > Correspondents bug on my install. Now I have to keep everyone in the > facility off of 45.0 until I can replicate this fix on a machine by machine > basis. Kyle, you are welcome, glad I could help.

(In reply to Dan from comment #72) > A couple of hours ago I followed the instructions and changed the setting to > "false". And there has been no changge to the column headings in my Inbox. > What gives? (In reply to Jim Porter (:squib) from comment #73) > Did you follow all of the instructions in comment 53? In particular, steps 2 > and 3. I also followed the instructions in comment 53 -- exactly those steps. They don't help. They change the columns temporarily for the current folder. I then apply the folder settings recursively. Then I switch to another folder, and switch back, and the columns are back to Correspondents. Yes, I have disabled the preference as well, in about:config. This upgrade is a trainwreck.

Update: the steps in comment 53 do work. What broke the workaround for me was Mnenhy 0.8.6. (I need Mnenhy for "custom headers".) I installed Mnenhy 0.8.6.1 now, but it doesn't help -- with it the Correspondents field is back again, and cannot be removed permanently. This is very sad. Without Mnenhy, I can only choose FIXME or FIXME in View | Headers. The former is too little, the latter is too much. With Mnenhy, I could pick "Extended", and I could add just what I wanted to see (namely, Message-Id). Under Thunderbird 45, this functionality of Mnenhy is broken, and Mnenhy also makes it impossible to remove the Correspondents field from the email list view. In short: Mnenhy 0.8.6 and Thunderbird 45 are incompatible. What a pity.

FIXME or FIXME --> Normal or All

I still want to downgrade. I am concerned because I found this: https://support.mozilla.org/en-US/questions/1111920#answer-849608 Has anybody tried to downgrade from V45?

What a débâcle! I entirely agree with pootmonkey [61] and many others. I'm so glad I took the time to read the release notes and to have waded through this thread to the essential point : change the (Boolean, not String) value of mailnews.ui.upgrade.correspondents to false BEFORE visiting ANY folders. This, fortunately, works. I have great appreciation for all the work done by the Mozilla Community and I think TB is a great product. I'm also in favour of innovation, despite being an oldie from the early days of e-mail. But I also have great experience, not only from my own use of software but also from working with others and studying their reactions. I can tell those who think that forcing a change of this sort onto users just to make sure they know it's there, *is not the right approach*. I'm a developper myself and I know very well the satisfaction one feels from introducing something one feels is going to be useful, and especially the eagerness to see it being used. However, most users, myself included, do not like being subjected to such changes without warning, *prior* explanation and preferably an easy method of reversal. How many millions have blithely intalled TB45 and gone immediately to their inboxes without reading the release notes? I'm not a great fan of Google, Inc., but I use their services. They have ways of introducing novelties that are worth studying. I'm not saying that it's possible to do things the same way as a slick billion-dollar interface, financed by the advertising it has to attract, but surely it's possible to make users aware of a new feature without forcing it on them. Such as looking to see what columns they're using and whether they're mixing sent with received, then showing a tooltip or something. Or even a simple pop-up that shows until you click "Got it!" Best John

(In reply to John Thompson from comment #86) > change the (Boolean, not > String) value of mailnews.ui.upgrade.correspondents to false BEFORE visiting > ANY folders. This, fortunately, works. Yes it does (since I implemented it). There is no need to downgrade. Set the preference as described many times in this bug. Done. With TB 45.1 the correspondents column upgrade will be gone, so no need to worry about it any more. See bug 1268325 for details. Downgrading brings many problems. You have to deal with lightning versions and your remote content exceptions get lost since the database format was upgraded from TB 38.x to TB 45.0.

Well, unfortunately I have many many folders. There was some link to "Switch something" which I guess was this thread. But I didn't know I had to go down to #53 so the whole thread didn't help me. I tried to fix folders and "Apply to children" and trashed all over. As I understand, the config change works only on folders that have not been opened yet. So, I have many many folders that I opened and many many that I didn't. I tried to follow the thread you referenced and I have very little confidence that 45.1 will "know" how to get me back to where I was before 45 was installed. It looks like it will be next week. If so, maybe I can wait but I think the odds are 50/50 that it will be worse after 45.1 because of all the folders that have been mangled by 45. V38 may look a lot better after 45.1 comes out. Despite the "many problems" with downgrading.

Just to note that in hindsight (and food for thought) adding the pref to disable upgrade was a terrible idea. I think it basically prevented alpha/beta/nightly people from complaining so there were no real feedback until it hit release channels.

Given that is was my idea, I'd like to contradict here: Firstly, the preference was set to *do* the upgrade and it was hard to find. So all the alpha/beta/nightly people would have seen the upgrade. Being more adventurous, they didn't mind. Also, I think, you overestimate the number of alpha/beta/nightly people and their complaints. We have regressions in quite obvious functions like in bug 1267804 which shipped in TB 45 alpha/beta/nightly and no one noticed until TB 45 release. Sure, if Nightly doesn't start, we hear about it ;-) Secondly, the preference "saved" at least some people, those who didn't want the upgrade and read the release notes or the "New in" page. Thirdly, we now disabled the correspondents column even more in bug 1268325. There is not upgrade at all and you don't even see it in new folders and when applying the default columns. Was that a terrible idea, too? Please also take a look at meta-bug 1268702 for some further food for thought.

Besides, the feature was landed in bug 36489 on 2015-03-24. I as a nightly user complained about the first problems in bug 36489 comment #156 on 2015-04-09. I opened this bug here the same day and started a discussion one day later here: https://mail.mozilla.org/pipermail/tb-planning/2015-April/003762.html I was overruled. The only thing that was permitted was that preference. Yes, the new functionality was first delivered without the preference to alpha/nightly users and when some of them complained, read the tb-planning thread, they were overruled. Magnus, I agree: Ship it early, ship it obvious, but when you get feedback - Don't ignore it!! The terrible thing that happened here is not the preference as you say in comment #89. The terrible thing is that we tried to force something onto the users, and when there were complaints, we ignored them (or implemented the option to shut-up more experienced users, which are all alpha/beta/nightly people). Only when there was an outcry, we back-paddled.

(In reply to Jorg K (GMT+2) from comment #90) > Given that is was my idea, I'd like to contradict here: > > Firstly, the preference was set to *do* the upgrade and it was hard to find. > So all the alpha/beta/nightly people would have seen the upgrade. Being more > adventurous, they didn't mind. Being adventurous may actually be part of the problem. I'd bet they tend to be more accepting of change. They certainly will tend to be more able to fix what they don't like. And, although we have no data, I'd bet they also have fewer addons than release channel folk, and thus less likely to run into major complications caused by addons. Also, we don't *actively* solicit feedback about changes as agressively as we could - such that we tend not to hear about issues - it takes more than a few people giving feedback to get a proper sense of what the issues are and guage severity. (I'm not saying we didn't announce it somewhere like planning perhaps, but I know we don't take advantage of what's new and start page to solicit feedback. And the old Migration Assistant or something like it would have helped in that regard. Case in point, this 1 year old bug, until two weeks ago, only had a few people CC and those were all developers/triagers.)

(In reply to Jorg K (GMT+2) from comment #90) > Given that is was my idea, I'd like to contradict here: I'm not casting blame. This is just contemplation. > Firstly, the preference was set to *do* the upgrade and it was hard to find. But someone complaining would have been sent to change the pref (and apply preferred setting to all folders). > Secondly, the preference "saved" at least some people, those who didn't want > the upgrade and read the release notes or the "New in" page. It may have "saved" some testers. Surely in numbers it had the effect that *more* people were hit, since release channel is so much larger. > Thirdly, we now disabled the correspondents column even more in bug 1268325. > There is not upgrade at all and you don't even see it in new folders and > when applying the default columns. Was that a terrible idea, too? That's fine. The point is that it would likely have happened earlier without the pref present.

(In reply to Magnus Melin from comment #93) > > > Secondly, the preference "saved" at least some people, those who didn't want > > the upgrade and read the release notes or the "New in" page. > > It may have "saved" some testers. Surely in numbers it had the effect that > *more* people were hit, since release channel is so much larger. It certainly saved me. I'm a mainstream release channel user and luckily read the release notes and this thread. As for the reactions of beta/nightly users I expect it's quite difficult to judge. I imagine most of them will be, if not developers, techy and wary. Others will be on early releases for testing but not "real-life" usage, having more stable installations for regular usage on other machines. This means that they may have limited value when it comes to evaluating the reactions to the kind of change we're talking about here. As for noticing bugs before final release, someone cited the address book drag-drop bug as obvious or highly visible. Don't know about that, I never drag and drop from the address book, it's much quicker to just start typing a name. In my experience drag-drop or even clicking to open a list is more used by mainstream; in many use cases mice are too slow for power users.

This is ****. "Apply columns to..." is not helpful at all, because it doesn't seem to distinguish between different types of folders. How can I set all inboxes to show a "From" column and all sent folders to show a "Recipient" column? If this is not possible, the forced upgrade should never have been deployed.

That's bug 562266, which I've posted a patch for, and which I'll try to get into the 45 branch (but probably not for 45.1).