464973 - "Expanded Columns" in the folder pane are no longer available to select columns for display for message total count and folder size

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect, P2)

Description

[Jay Rossiter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081113 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081113 Lightning/1.0pre Shredder/3.0b1pre

The "Show Expanded Options in the Folder Pane" (Advanced Options) is no longer functioning, starting with 11-13 nightly.

The column header configuration button is missing, and pre-configured columns disappeared upon upgrade.

Reproducible: Always

Steps to Reproduce:
Upgrade to 20081113 nightly.

Comment 1

[Magnus Melin [:mkmelin]]

This is from bug 414038, see bug 414038 comment 96, bug 414038 comment 100.

Comment 2

[Mark Banner (:standard8)]

This is an intentional regression to allow us to land code that enables development to advance quicker in multiple directions. David and Bryan need to file bugs on the UI that will replace the columns.

Comment 4

[Joey Minta]

Attachment: patch v1

I did promise I'd restore this functionality, despite my disagreements with it. This patch also fixes bug 465267.

NOTE: nsTextFormatter doesn't seem to be available to javascript, making the MB/KB labels difficult to deal with. The simplest option was to switch the %d to %S. The problem here is obviously that we're past the string freeze. Option 2 is to (temporarily) hardcode those strings and then re-localize them post-beta1. Option 3 is to hold this patch until post-beta1.

Comment 5

[Joey Minta]

Simon,
   Can you comment on the concerns addressed in comment #4. How often do "MB" and "KB" require a translation? How glaring would it be to have hard-coded values?

Comment 6

[Joey Minta]

Option 4 would be to use the toolkit versions of these strings (used in the download manager) http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties#50

Comment 7

[Bryan Clark (DevTools PM) [:clarkbw]]

Lets not add these columns back in.  The extra columns require an advanced pref to be turned on.  There is a lot of wasted space that your folder pane such that it requires a large amount of space for all the numbers to be visible.  You could spend a lot of time resizing the columns to make sure everything fits with optimum space.  You can't even sort by the columns, not that we really want to.  None of that seems like a good experience, I'm pretty sure the ENIAC had clearer readouts than this layout.

Plus the use case for this is fairly unclear (at least to me) exactly what people need here, especially compared to what we had planned.  From what I understand the expanded columns provides 3 extra pieces of information.

* Unread
* Total
* Size

For the unread column we should be providing the number beside the name of the folder so people can see how many are actually unread.  I'm not sure why we haven't been doing this all along.  This should be on by default.

*Inbox (2)*

With this we should also be able to provide an option to show the total number of messages as well.  (this doesn't come out looking good in ascii art because it requires font color changes and the bold needs to wrap around but the effect is simply like this.)

*Inbox (2*/320*)*

And though I seriously doubt that people need constant visible dashboard of the size of their folders... this could be done as well with a light colored font (indicated by the //) instead of a separate column.  I'm sure there are lots of people who've grown accustomed to this feature but I think there's a better way to manage or monitor space.

*Inbox (2*/320*)*  //5KB//

We might want a separate chooser for which folders show this kind of folder details or a per folder [x] for "folder details" would allow people to get that extra information they want on a per folder basis.

Comment 8

[Jay Rossiter]

Unless you are going to add an option to right-justify the Read/Unread information, I don't feel that what you're suggesting comes close to what the previous behavior provided.

I, for one, have always felt that reporting the unread counts as (essentially) part of the folder name is bad UI design.  I have always found that layout to be very difficult to visually scan, especially when multiple levels of folders are involved.

I want to be able to scan down a *single* column of information that will give me the data that I require about my folders, without having to continually scan back and forth through multiple levels of nesting to see it.  I don't want to have to read every folder name (bold not withstanding) - it's supposed to be informative, not a novel.

And yes, I *do* require a "constant visual dashboard of the size of [my] folders".  Your workflow may not include these, but for many people, it does.

Comment 9

[Jay Rossiter]

Note: 'size' means number of messages, to me.  Folder size in SI units doesn't matter to me, though I'm sure it does to others.

Comment 10

[Simon Paquet [:sipaq]]

(In reply to comment #6)
> Option 4 would be to use the toolkit versions of these strings (used in the
> download manager)
> http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties#50

That sounds like a good solution to me.

Comment 11

[Mark Banner (:standard8)]

(In reply to comment #7)
> We might want a separate chooser for which folders show this kind of folder
> details or a per folder [x] for "folder details" would allow people to get that
> extra information they want on a per folder basis.

I think we'd want both - show folder size in the properties dialog, and a
dialog to show all of them at once. Although that's a bit of duplication,
having them all together at the same time I expect would be wanted by most
people.

(In reply to comment #8)
> And yes, I *do* require a "constant visual dashboard of the size of [my]
> folders".  Your workflow may not include these, but for many people, it does.

Why? If you didn't have the numbers, what wouldn't you be able to
do/judge/decide? Please give us actual use-cases so as to help us understand
why you really need it.

Comment 12

[David Ascher (:davida)]

The use case for showing total count is, from the interviews I've done, that some people want some folders to be empty, and manage their workflow so that their work is not done until that count is 0.  For everyone I've talked to, that requirement applies to _a few_ folders, not all.  

I'll be filing a bug after chatting w/ clarkbw to specify how people can set that UI on a per-folder basis.   

I'll also file another bug about giving people a way to manage the overall space (both counts & size) of their accounts, which is a great use case which I don't think is best suited by the folder pane.  

I believe that these two new capabilities will provide even better UI for the use cases we've identified, and let us have heterogeneous items in the folder pane, which in turn will be very helpful for other use cases.

Comment 13

[David Ascher (:davida)]

Followup Bugs 465564 and 465568 have been filed. 

If there are other use cases which those two bugs don't solve, let's file new bugs and deal with those there.

Comment 14

[Jay Rossiter]

Requiring users to configure that layout *per folder* is ridiculous.  I have several hundred folders, and I want it enabled in every single one.

#465564 also does not provide for display in a column format, which as I stated in comment #8 is critical, IMO.   My folder list should be visually scanable - it's not a novel that I should be required to read line by line to determine the information I'm looking for.

Attaching those pieces of data to the folder name is not a user-friendly UI.

Whether you like it or not, unless it comes very close to the legacy feature, it's not going to be adequate.

Comment 15

[David Ascher (:davida)]

Jay -- please answer Mark Banner's question about the goals that you're trying to achieve, not by describing the specific UI you want, but by describing the underlying needs.  Then we can figure out how to best deal with those goals.

Comment 16

[Jay Rossiter]

The use you listed in #12 is a big one
Overall message count as an identifier for archival and/or purging is another.

It also seems like you don't understand that the layout of the UI *is* part of the goal, and it's at least as important as the first use case.  The ability to quickly scan a column for information about my folders is a use case in itself.  

If columns were of no informational use, we'd just do all our spreadsheets in a text editor.  Without a column alignment, the user must scan the entire line to determine the information they're looking for.  It's slower and more frustrating, especially to people who use email all day long.

The folder name is one piece of information, unread is another, total count is yet another.  They need to not be grouped together as if they were all a single piece of data.

Comment 17

[Jay Rossiter]

Another way to look at it:

If all the data about a folder is a single piece of information (and thus represented in a single column), then all of the data about a message is also a single piece of information.

All of that data represents a single message, therefore it must not warrant extra columns either.  (Sorting can be done without columns, so that alone is not a reason to keep them in the message pane.)

So, why does the message pane have multiple columns?  Because it's easier to read large amounts of data that way.

Comment 18

[Przemyslaw Bialik]

Maybe bring back option to turn on folder pane columns with advanced pref and work on the bugs that should imitate the usage they were providing ?
When all these bugs would be fixed it can be decided if "classic" display is still needed or modern one should cater all user needs.

Comment 19

[David Ascher (:davida)]

Jay, re usage in #12 -- do you need to work hundreds of folders down to a count of 0?  

Re: the advantages of columns: what are you looking for when vertically scanning through the # of messages?  

About the information-theoretic approach -- there are lots and lots of information about folders that we could display.  # of Unread messages is of value to a lot of users for most folders.  # of read messages is of value to a fair number of users for a few folders.  

From a cognitive point of view, having numbers displayed that do not help the user accomplish what they're trying to do will make it harder for them to find the information they need.

As a bit of background, one additional problem with the columnar model is that it doesn't apply to non-folder things.  We want to move to a world where we can have things other than folders in there, such as calendars, todo lists, who knows what.  It may be that for some users, having the columns is the best way to do things, but we don't want to limit the extensibility of the folder pane because it's been "just" a folder pane. 

It'd be interesting to build an add-on that reinstated the columns for those users who desperately need them.  I'm still trying to drill down on the actual benefit that those columns provided, because I still think that in many cases, we can provide the same benefit without compromising the extensibility of the UI.

Hope this helps.

Comment 20

[Przemyslaw Bialik]

(In reply to comment #19)
> As a bit of background, one additional problem with the columnar model is that
> it doesn't apply to non-folder things.  We want to move to a world where we can
> have things other than folders in there, such as calendars, todo lists, who
> knows what.  It may be that for some users, having the columns is the best way
> to do things, but we don't want to limit the extensibility of the folder pane
> because it's been "just" a folder pane.
so in other words the only workaround for not wanted columns applying to non-folder things is to fully remove the columns ?
if these new things would not be folders couldn't they "not fully" integrate to the folder pane such that columns would not apply to them ? (or stick columns to the local folders or sth like this)

Comment 21

[David Ascher (:davida)]

Przemyslaw: unfortunately, as far as I know the implementation of columns in the current XUL tree widget doesn't let us do "per-kind" columns.

Note that there is a gecko bug which would allow us to do richer styling of treecells (bug 441414),  which should allow us richer ways of displaying things, so we should be able to do column-like displays in the future.

Comment 22

[Przemyslaw Bialik]

Thanks for the bug id, I've heard about it but didn't yet read it.
So with this bug fixed (there is some work already) there could be no topic ? adding dependency ?

Comment 23

[Joey Minta]

I've create an extension which turns on these columns (as opposed to using a preference). To use it, you must have today's nightly or later, though. You can give it a try here: https://addons.mozilla.org/en-US/thunderbird/addon/9716

Comment 24

[Bob Lord]

Here's my personal use case:
I use the number of total messages as a to-do list, with a goal of getting to zero.  I use that functionality for the Inbox and Drafts folders on a regular basis, and perhaps on a less frequent basis for other folders.

I do want to be able to see the total number of messages for a given folder. I can do that today in the status bar, so that works in my case as a workaround.

I use IMAP folders. Sometimes I run up against a quota and have to move mail messages locally.  I need to be able to find the biggest folders to take action.  Sometimes it's just one message with a big attachment.  Sometimes it's just that I have thousands of messages.  Either way, I need a way to find the bloat.  I don't care what mechanism the client provides.  

The suggestion of grouping the info together works for me if there's a pref to enable the verbose mode:
*Inbox (2*/320*)*  //5KB//

But I wouldn't care if that information was provided in some other way.  For example, I sometimes use the Zimbra web mail/calendar interface.  That UI presents the number of unread:
*Bugzilla (50)*
and then provides a tooltip that contains the total number of messages, and the folder size.

Anyway, just some data points. Hope that helps.

Comment 25

[Worcester12345]

(In reply to comment #7)
> Lets not add these columns back in.  The extra columns require an advanced pref
> to be turned on.  There is a lot of wasted space that your folder pane such
> that it requires a large amount of space for all the numbers to be visible. 
> You could spend a lot of time resizing the columns to make sure everything fits
> with optimum space.  You can't even sort by the columns, not that we really
> want to. 

This is not true! I would absolutely love to be able to sort by the folder size. We have an ISP limit on IMAP storage, and this would help greatly in order to identify if some large messages are lurking somewhere in a mailbox.

Comment 26

[Bryan Clark (DevTools PM) [:clarkbw]]

Sorting folders by size is an excellent idea.  Sorting the folder pane by size isn't necessarily the best way to accomplish this hunt for large messages.  

Another view that is specifically tuned towards helping people manage their space, especially good for quota management, would help with this.  Something this view could provide is a much more detail breakdown of where the space is being used.  Attachments vs. Messages is something that would be an interesting way of analyzing this information.  

 Name         Count  Size (MB)
 -----------------------------
 Folder X            630
   Messages     400  430
   Attachments  22   200

Also, with more space in a, say separate tab, we could offer graphical breakdowns of each account and folder.  Or... we could try to cram little pie charts into the folder pane :)

Like Bob mentions in comment 24, managing size is something that people need to do.  However we can do this in a much nicer way than overloading the folder pane.

Comment 27

[Worcester12345]

(In reply to comment #26)
> Sorting folders by size is an excellent idea.  Sorting the folder pane by size
> isn't necessarily the best way to accomplish this hunt for large messages.  

It is for me. I see the largest folder. I click on it. I sort by message size. Find a few and delete or move. It cannot get any simpler. This is why this bug needs to get fixed!

Comment 28

[Joey Minta]

Please, let's not get sidetracked on what is already a contentious bug. This bug exists solely to debate restoring the columns. A separate bug would handle sorting by those columns. Nonetheless, I've provided the extension that does the first part (see comment #23), which I think is all the more reason to WONTFIX this bug. That extension brings the behavior back for those who want it.

Comment 29

[Worcester12345]

I'm sorry, I just want to view the columns, as you said. I don't care about sorting until I open the folder. Thanks to those working on this bug to bring back the columns.

Comment 30

[Joey Minta]

In line with comment #23 and comment #28, I'm resolving this as WONTFIX. For those that want the columns, installing the extension will provide them. As davida described, the thunderbird core is looking at other solutions beyond the folder-pane.

Comment 31

[Ronald Killmer]

(In reply to comment #23)
> I've create an extension which turns on these columns (as opposed to using a
> preference). To use it, you must have today's nightly or later, though. You can
> give it a try here: https://addons.mozilla.org/en-US/thunderbird/addon/9716

Where do we report bugs for this extension?
Also, look at Bug 297853 where some Icon attachments show an alternative to text labels. With Icons the Col width can be cut to ~2.4em.

Comment 33

[Frederic Bezies]

I know this will be unuseful to say this but wontfixing this bug is a regression in both usability and interface display.

If you want to push user out of thunderbird, it could be a solution. Having some kind of columns - just to know number of messages in each folder - is something which is present in every single mail client.

Just my opinion, of course.

Comment 34

[Joey Minta]

(In reply to comment #31)
> Where do we report bugs for this extension?
You can add comments/review to the add-on with bug reports. I know the management panel discourages that, but amo doesn't have a better system worked out yet.

(In reply to comment #33)
Is there some reason that the add-on is insufficient for your needs (or the needs of the other users that you say will be pushed out)?

Comment 35

[Frederic Bezies]

Just for you info, I installed the extension since. But it will be far better to get these columns back in any form.

Many people won't search for an extension for such a basic feature, even if it fills the gap left by this bug.

Comment 36

[Robert Kaiser]

Frank, we probably want some version of the patch here or the mentioned add-on in the SeaMonkey version of the JS-driven folder pane.
Sorry for the bugspam to everyone else.

Comment 37

[Worcester12345]

60+ users here, and now considering our options if this sort of thing gets swept under the rug.

Comment 38

[Eugene Savitsky]

Defenetly a regression for me. 

What is the point not including this functionality in the 3.0, when it was in Tb2.0 and is available as an extention (have not tried it, since I stay on pre-this-bug build)?

Comment 39

[Rimas Kudelis [use needinfo to ping]]

Come on, right now I dislike it too, but if Mozilla guys want to make something even better up, why not let them at least try it before saying that it's just plain wrong?

Let's just install the extension from Comment #23 for now, and watch those other bugs.

Comment 40

[Wim]

Agree from me also that this is a regression. My question is, why especially do you want to have it out when it is an _option_ people might or might not use? If you don't use/like it, just turn it off (which it is, when you do a clean install). If you don't want to waist the space on your screen, turn it off. This is about choices! Please put the "option" back in.
My personal use:
- workflow using the number of messages; I don't use unread
- Size for the need to compress yes/no (I know it can be done automatically, but I want to control it myself).
Of course, if the development team comes up with another solution I am open for it , but just bumping it out seems a bit to simple.

Comment 41

[pdpd]

> (In reply to comment #33)
> Is there some reason that the add-on is insufficient for your needs (or the
> needs of the other users that you say will be pushed out)?

I found the add-on after some agressive Googling, and thank you for it!  (Can you eliminate the unnecessary zero for folders with no unread message, though?  That would fully restore the previous usage and would be much appreciated.)  But I agree with those here who say that a useful feature has been lost, and I imagine many users will not know to look for the add-on that restores it.

Comment 44

[Bryan Clark (DevTools PM) [:clarkbw]]

For future reference the add-on for this is located here:
https://addons.mozilla.org/en-US/thunderbird/addon/9716

Comment 45

[Mugros]

I use the unread message count to watch my emails which i have yet to process. That is not equal with being unread, because i might read an email and decide to process it later. That's why every email is tagged as to-do on receiving. And then i have a smart folder which catches all emails with this tag.

That the reason why i need the total column.

And then i automatically sort my incoming email. This way the unread mail is distributed over several folders. Putting the unread message count directly behind the folder name is really a regression in usability. I would say it is a usability nightmare. Yes, you can find the unread emails, but it much harder than having the separate column. As someone pointed out, you can't scan over your folder tree quickly to find unread mail. (And don't let me start about the grey folder names.) Even Outlook Express does it better with the unread count in blue instead of black. Try to find a '(1)' in a mix of long and short folder names and then in a separate column. Whoever came up with the idea to concatenate the folder name with information about the content should be really ashamed.

That's the reason why i need the unread column.

reply to comment 7:
A lot of wasted space? After installing TB3 i thought about the amount of unused whitespace. 
Please check the calender. It is almost 2010. Almost everyone is using widescreen monitors. Most emails are wrapped after 72 characters. And even if the email is not wrapped after 72 characters but are auto-wrapped in the message pane, the longer the text lines the harder it is to read the text. So what is the reason to gain 30 pixels of horizontal space if there is no shortage of space in that direction? (And to be honest, i don't even use a widescreen monitor with TB, at least not for the main window. Still i don't need extra space and would rather have a usable display of unread messages)
And even if you would really need the additional space, the argument is flawed, because if there is an unread mail in the folder with the longest name, the unread message count is displayed exactly where the column would be. No big difference. (Yeah, i know the folder name will be shortened in the middle, but i hate that.)

So, why don't do it as an add-on?
1. Hard to find. I normally find almost everything, but this add-on was shown to me in a forum. If you try to find a solution to get the columns view back, you only find how to enable it in TB2.
Many users probably won't find it and would blame TB because it lacks this option.
2. The add-on is not localized, it's only in english. No big deal for me, but definitely for others.
3. Add-ons depend highly on the author. If new version of TB are released the compatibility is checked too late and the add-on will be disabled. And after some time the author might lose interest in the add-on and abandon it.

The removal of this option is a bad decision.
At least make the unread message count configurable, so that it can be aligned to the right side of the folder pane.

Comment 47

[eric raeburn]

Can someone explain how to use the add-on referenced in this thread?  First, on installation (on TB3.0), it complained about a version incompatibility.  I unzipped the add-on, changed em:maxVersion to 3.0 in install.rdf, and zipped it back up again.  Then the installation appeared to work, but after TB was restarted, the functionality was not there, nor was the add-on listed under Tools > Add-ons.  TIA.

Comment 48

[eric raeburn]

RE: Comment 47: I hacked a fix.  For some reason, during installation, the folder "chrome" did not get copied from the add-on archive into its proper destination.  Manually copying it made it work, and also allowed the add-on to be listed under Tools > Add-ons > Extensions.

Comment 49

[Emil Hatfalvi]

(In reply to comment #48)
> RE: Comment 47: I hacked a fix.  For some reason, during installation, the
> folder "chrome" did not get copied from the add-on archive into its proper
> destination.  Manually copying it made it work, and also allowed the add-on to
> be listed under Tools > Add-ons > Extensions.

Would it be too much to ask for a consolidated "how-to" for making this actually work with TB3.0?

This functionality *really* should be put back into TB3.0.  I have no problem with it being enabled by an advanced setting, but an "add-on" seems excessive and short-sighted.

Comment 50

[Bernie]

Amen to Emil's comments (both of them) and to the MANY other requests from people technically savvy enough to use Usenet.  Imagine how many people that don't use newsgroups or bugzilla are disappointed.  Between this regression and the abhorrent waste of space in the new headers I abandoned the TB3 betas and will remain on TB2 and encourage others to do that too.  If the functions are not eventually restored then at some point we will look for another alternative mail and news program.

Add-ons can never be counted on to be kept current with TB releases, let alone version changes.  That makes them undesirable for those of that are technical and unpleasant for those of us that provide technical support to others.

Comment 51

[Alonso Acuña]

I spent several days looking for a solution to be able to see the columns which are super important for me. As I gave up and decided to report the bug I found this and realize that somehow it is a big issue. I dont understand why the feature was removed and personally think it should be fixed. Just look at how many people are reporting this as a bug. At least put a link to the extension in the release notes or have it presinstalled or something. Just removing a feature with no notice is really bad.

Comment 53

[Alonso Acuña]

the addon https://addons.mozilla.org/en-US/thunderbird/addon/9716  is now compatible with TB3.0  It is so strange that this functionality migrated from the core to an addon, why did the developers wasted time removing this, and force people to install the addon? If the addon is so simple why not bring the feature back?

Comment 56

[Worcester12345]

Staarting to build up the duplicates here. Maybe it is time to reopen this bug.

Comment 60

[Kent James (:rkent)]

I complained about this issue before this bug was even filed in bug 414038 comment 75. The addon referenced in this bug, that was only originally created (under protest by the author) because some of us complained, is now the third most popular extension for Thunderbird, behind only Lightning and it related google provider extension.

It seems like events have made it pretty clear that this was a mistake to remove. Changes to the folder pane that were supposed to be done that added new features never occurred, the popularity of the addon shows that users believe there is a use case for this, and promises to add better ways to get at the data never occurred. Meanwhile the addon itself was abandoned by its original author, and taken over by core Thunderbird developers because it is so critical.

Can we ever admit a mistake? Let's admit it, reopen this bug, and merge the functionality of the addon into core.

Comment 61

[:aceman]

Yes, I vote for this and would be willing to work on this. I am familiar with the code of the Extra folder columns extension and I have fixed some stuff in it, even added the display of accumulated subfolders data if the parent folder is collapsed.

We just need confirmation from UI guys and reviewers that it would be accepted back into core. The columns turned off by default but normally exposable, no pref needed.

Comment 62

[Blake Winton (:bwinton) (:☕️)]

The extra functionality that was hoped for never did appear, but having extra columns in that tree view seems really odd, and crufty, to me.  We'll see what Josiah and/or Paenglab think, but I would accept a patch that re-added the columns if, and only if, it didn't add an extra line of header to the default configuration.  (Also, it's hard for me to give a more firm commitment without seeing a screenshot.)

Comment 63

[Kent James (:rkent)]

(In reply to Blake Winton (:bwinton) from comment #62)
> The extra functionality that was hoped for never did appear, but having
> extra columns in that tree view seems really odd, and crufty, to me.  We'll
> see what Josiah and/or Paenglab think, but I would accept a patch that
> re-added the columns if, and only if, it didn't add an extra line of header
> to the default configuration.  (Also, it's hard for me to give a more firm
> commitment without seeing a screenshot.)

What do you mean by an extra line of header?

Comment 64

[Josiah Bruner [:jsbruner]]

Attachment: Screenshot

I'm pretty sure he means the header that appears at the top of the folder pane (See screenshot). I completely agree that this should *not* be shown by default and should be hidden with a preference. Not necessarily hidden in about:config, but not visible by default.

Comment 65

[:aceman]

Then how do you propose the user enables/toggles the additional columns?

Comment 66

[Blake Winton (:bwinton) (:☕️)]

Hidden pref, of course!  ;)

(More seriously, there are already options that control the folder pane in the View menu.  Something there seems appropriate.)

Comment 67

[:aceman]

Great, so instead of standard UI and tree infrastructure (e.g. the column picker widget) we open-code some new UI used nowhere in TB :)

Comment 68

[Blake Winton (:bwinton) (:☕️)]

A menu option to show a table header is hardly new.  :)

Comment 69

[:aceman]

It is, if you call it "table header". If you at least call it "toolbar" then yes, that does already exist :)

Comment 70

[Kent James (:rkent)]

We seem to have a fundamental disagreement about the importance of this option. Since 200,000 users managed to install this addon (which requires a lot of effort to even know it exists) then it is pretty clear that this is important functionality. If we have important functionality, we should be exposing it so that it is easy to find. The users have already spoken pretty clearly that this is important. It seems to me that the onus is one you guys, Blake and Josiah, to say why you believe that the usual interface for exposing folder columns should be hidden in this case. Buried in a menu is far from clear.

If it were fully up to me, I would add a folder pane header that had a dropdown menu to select the folder type on the left, and the standard icon to show columns on right. The ability to switch folder display types is also functionality that was buried for reasons I never understood (and yes I use the addon that restores that functionality).

I don't understand "but having extra columns in that tree view seems really odd, and crufty, to me" What is the issue here?

Comment 71

[:aceman]

It seems hiding/showing the column headers is doable. So it can be toggleable as an option in View->Folders.

Comment 72

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #71)
> It seems hiding/showing the column headers is doable. So it can be
> toggleable as an option in View->Folders.

This sounds like a good place.

Can we also add the expunged column of the addon in bug 750569?

I also need to point out that a review in https://addons.mozilla.org/en-US/thunderbird/addon/extra-folder-columns/ states "... on TB31.1, TB has a strange behavior when I enable the display of the SIZE column: When I scroll the folder pane, TB freeze few seconds. When I disable the SIZE column, the scrolling is fine."  

Coincidentally, I am working with a user who experiences slowness with message deletes with this addon and gfx.direct2d.disabled = false (true resolves it).  Not sure yet if it is also slow when scrolling folder pane.

Comment 73

[Josiah Bruner [:jsbruner]]

(In reply to Kent James (:rkent) from comment #70)
> We seem to have a fundamental disagreement about the importance of this
> option. Since 200,000 users managed to install this addon (which requires a
> lot of effort to even know it exists) then it is pretty clear that this is
> important functionality. If we have important functionality, we should be
> exposing it so that it is easy to find. The users have already spoken pretty
> clearly that this is important. It seems to me that the onus is one you
> guys, Blake and Josiah, to say why you believe that the usual interface for
> exposing folder columns should be hidden in this case. Buried in a menu is
> far from clear.
> 

Since this is a popular feature, I have changed my mind about saying we should *not* show it by default. I actually think it's fine to show by default. However, I would like a way to hide it, since it does add clutter to the pane, and I (and many others), will want to remove it. But of course, an add-on could be made to hide it quite easily, so let's just move ahead with this bug.

Comment 74

[Wayne Mery (:wsmwk)]

As a long time user, not saying I'm representative, I'm in the "wanting cleaner UI, i.e. no column header camp" so I'd want at minimum a non-addon method to not show column header.

> We seem to have a fundamental disagreement about the importance of this option. 
> Since 200,000 users managed to install this addon (which requires a lot of 
> effort to even know it exists) 

I'm not one to be a naysayer, but I'm going to play devils advocate 
- I'm not convinced that it is difficult for users to find said functionationaility - do we have information that indicates this?  And, if it is difficult does that not say more about lack of publicity, visibility and findability of addons ... a big failing on our part?
- Further, 200k may be a large number but I'm not convinced that 200k means that a significant percentage of the other 12M users (or whatever the number is) would want this.

Comment 75

[Kent James (:rkent)]

I'm happy to have it disabled by default, but it would be good if there was some hint at the point of the missing columns that shows that there is something there that is hidden. I'm not sure what it is called, but I will attach a file that shows the arrow in the separator that is sometimes used.

As for "I'm not convinced that it is difficult for users to find said functionationaility":

There is a hierarchy of feature discovery here:

1) Always shown
2) not shown but contextual hint (which is what I want)
3) not shown, but enabled with a non-contextual preference ui (what blake wants)
4) not shown, you have to locate an addon to find that it even exists
5) enabled with a hidden preference.

You think 4 -> 2 is a small leap, I think it is a huge leap. And 200k is massive in the context of addons for Thunderbird. 2% of our users using anything but a core feature is already huge.

Ideally, what I would expose in the extra line would contain, on the left, a dropdown box to allow you to select different folder groups (All, Smart, Favorites, etc). and also show the treeview column icong that hints that more icons can be seen.

Comment 76

[Kent James (:rkent)]

Attachment: What do we call this UI with the arrows that hints that something exists?

Comment 77

[Magnus Melin [:mkmelin]]

That's a grippy. They're a bit out of fashion though.

I think I'm somehere around #3, like Blake. We'd need a menu item kind of thing somewhere anyway so... 

It would be nice if there was a way to customize the folder pane in general. Choosing folder modes, combining folder modes etc.

Comment 78

[Blake Winton (:bwinton) (:☕️)]

We could have a floating disclosure arrow, like the one at the right of https://www.dropbox.com/s/i5i2xrs2ua3fge7/Screenshot%202014-10-20%2009.35.29.png?dl=0  I don't know how it would look in context, but perhaps that would be a reasonable compromise?

(This is all in addition to the menu item, which I believe everyone agrees we should have. :)

Comment 79

[:aceman]

(In reply to Kent James (:rkent) from comment #75)
> You think 4 -> 2 is a small leap, I think it is a huge leap. And 200k is
> massive in the context of addons for Thunderbird. 2% of our users using
> anything but a core feature is already huge.

Based on the numbers presented recently on the summit, this actually makes it the 4th most used addon for TB. So I think having a separate addon for this simple and small functionality is strange.

Ok, I'm going to code something up :)

Comment 80

[Wayne Mery (:wsmwk)]

(In reply to Blake Winton (:bwinton) from comment #78)
> We could have a floating disclosure arrow, like the one at the right of
> https://www.dropbox.com/s/i5i2xrs2ua3fge7/Screenshot%202014-10-20%2009.35.29.
> png?dl=0  I don't know how it would look in context, but perhaps that would
> be a reasonable compromise?
> 
> (This is all in addition to the menu item, which I believe everyone agrees
> we should have. :)

I was thinking the same thing, because in general discoverability s*cks all around - I'm all for discoverability that doesn't impede the rest of the UI. This could easily cover comment 77, which are also not so discoverable. 

As Kent says it may be a big leap for a user to know that something could improve the folder pane. What I was only suggesting is it isn't worse than anywhere else in our UI. But we don't have metrics on whether users know that addons exist and how to get one that's relevant to their needs But if we think users finding functionality via addons s*cks then we should go a step further and improve it (which is a different bug) ... wouldn't it be great if right+click (or something) allowed a user to look up addons in context of the UI area being clicked?

Comment 81

[Kent James (:rkent)]

"in general discoverability s*cks all around ... I was only suggesting is it isn't worse than anywhere else in our UI" is not a particularly strong argument for avoiding discoverability.

Comment 82

[Worcester12345]

(In reply to :aceman from comment #71)
> It seems hiding/showing the column headers is doable. So it can be
> toggleable as an option in View->Folders.

A checkbox or radio button would work. You know, like the green "Read/Unread" button?

Comment 83

[Worcester12345]

(In reply to Magnus Melin from comment #77)
> That's a grippy. They're a bit out of fashion though.
> 
> I think I'm somehere around #3, like Blake. We'd need a menu item kind of
> thing somewhere anyway so... 
> 
> It would be nice if there was a way to customize the folder pane in general.
> Choosing folder modes, combining folder modes etc.

(In reply to Blake Winton (:bwinton) from comment #78)
> We could have a floating disclosure arrow, like the one at the right of
> https://www.dropbox.com/s/i5i2xrs2ua3fge7/Screenshot%202014-10-20%2009.35.29.
> png?dl=0  I don't know how it would look in context, but perhaps that would
> be a reasonable compromise?
> 
> (This is all in addition to the menu item, which I believe everyone agrees
> we should have. :)

(In reply to Worcester12345 from comment #82)
> (In reply to :aceman from comment #71)
> > It seems hiding/showing the column headers is doable. So it can be
> > toggleable as an option in View->Folders.
> 
> A checkbox or radio button would work. You know, like the green
> "Read/Unread" button?

How about just plain old "More..." up above where the columns would be?

Comment 84

[:aceman]

Attachment: patch v2

WIP patch of the feature. It basically puts the "Extra folder columns" extension directly into TB core, main part in folderPane.js. It also contains my modifications (like localization fixes, summarizing of the properties across subfolders). I've been running with most of the modifications for about 2 years now.

You can enable the column headers via View->Layout->Folder pane columns (until you do that, the current default display should not be affected by this patch). This integration into TB is all new, so please check it and see if it is the right approach. I also use a global pref for it, so all windows with a folder pane share the setting. E.g. the folder pane itself can be toggled per window.
Toggling the columns in one window will not toggle them in all other windows. But will save the global pref so after restart all windows are the same. Not sure if the dynamic toggling is necessary.
There are also some open questions. E.g. if we want to hide the additional columns if "folder pane columns" are toggled off? Or they just stay there without headers?

Strangely the patch does not contain some stuff Joey's patch v1 is doing. I don't know if the missing parts are needed as the addon was also going without them. Maybe the XUL platform has improved since 2008?

Comment 85

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8528640 [details] [diff] [review]
patch v2

(Redirecting to Josiah, because I think he and I are on the same page, and I'm going to be crazy busy for a while…)

Comment 86

[Kent James (:rkent)]

Comment on attachment 8528640 [details] [diff] [review]
patch v2

Yes I like it! Thanks for doing this.

I'm not completely sure about the star added to note that a folder is a summary. I like the idea of arking this (I've been fooled before by the lack of such a marker) but not sure about the star. I tried sigma and sigma blank, did not like them better. Underlining is another common nomenclature for a sum, perhaps that might work.

But I can live with the star.

The other thing that we really need, and perhaps you could add in another bug, is some better method to switch between folder display styles. That is, replace the "Name" part of the column header with a dropdown that allows you to select which folders are being viewed.

Comment 87

[:aceman]

(In reply to Kent James (:rkent) from comment #86)
> I'm not completely sure about the star added to note that a folder is a
> summary. I like the idea of arking this (I've been fooled before by the lack
> of such a marker) but not sure about the star. I tried sigma and sigma
> blank, did not like them better. Underlining is another common nomenclature
> for a sum, perhaps that might work.
> 
> But I can live with the star.
Yes, the star is just a placeholder character and we can now get the UX guys to choose a better one for English. I have made it localizable so any language can choose its own fitting character.

> The other thing that we really need, and perhaps you could add in another
> bug, is some better method to switch between folder display styles. That is,
> replace the "Name" part of the column header with a dropdown that allows you
> to select which folders are being viewed.
I didn't understand this. What are the options for which folders could be viewed? We have the View->folders menu. Looks like this is for a new bug if you could spec the feature more thoroughly.

Comment 88

[Kent James (:rkent)]

I've reopened bug 700976 for the issues I suggested in comment 87.

Comment 89

[Josiah Bruner [:jsbruner]]

Comment on attachment 8528640 [details] [diff] [review]
patch v2

Review of attachment 8528640 [details] [diff] [review]:
-----------------------------------------------------------------

I like this for the most part and I think it's pretty much fine. However, the extra columns should definitely be removed from the pane when you uncheck "Folder Pane Columns". Other than that, looks good to me.

Comment 90

[:aceman]

Attachment: patch v3

OK, I addressed the remaining issues. So this could be ready for review.

Aryx, please push to try server, all tests.

Comment 91

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Pushed to try-comm-central: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=9c17c931a2d7

Comment 92

[Kent James (:rkent)]

Comment on attachment 8557379 [details] [diff] [review]
patch v3

Review of attachment 8557379 [details] [diff] [review]:
-----------------------------------------------------------------

There were a few small nits and one comment with substance. r=me with requested changes implemented.

::: mail/base/content/folderPane.js
@@ +2223,5 @@
> +                "folderWithAccount", [text, this._folder.server.prettyName]);
> +          }
> +
> +          // If the unread column is shown, we don't need to add the count
> +          // to the name

Nit: period at end of sentence.

@@ +2235,5 @@
> +                                  [text, gFolderStatsHelpers.addSummarizedPrefix(unread)]);
> +          return text;
> +
> +        case "folderUnreadCol":
> +          return gFolderStatsHelpers

Nit" missing ; at end

@@ +2239,5 @@
> +          return gFolderStatsHelpers
> +                   .fixNum(this._folder.getNumUnread(gFolderStatsHelpers.sumSubfolders));
> +
> +        case "folderTotalCol":
> +          return gFolderStatsHelpers

Nit: missing ; at end

::: mail/locales/en-US/chrome/messenger/messenger.properties
@@ +485,5 @@
> +## %1$S = folder name
> +## %2$S = account name
> +folderWithAccount=%1$S - %2$S
> +## LOCALIZATION NOTE(folderWithUnreadMsgs):
> +## This is a concatenation two strings to compose a folder label with unread messages.

Nit: "concatenation of two strings"

::: mailnews/base/util/nsMsgDBFolder.cpp
@@ +4193,5 @@
>    NS_ENSURE_ARG_POINTER(numUnread);
>  
> +  bool isServer = false;
> +  nsresult rv = GetIsServer(&isServer);
> +  NS_ENSURE_SUCCESS(rv, rv);

I am seeing on a newly created IMAP account that the sizeOnDisk is -1 for the root folder, and stays that way after restart. That means that the UI always has ??? next to the imap account name. You fixed that issue in unread and totalMessages, but not in folderSize. Since that is calculated for each folder, you need to add this same check to the overridden values of GetSizeOnDisk for IMAP, local, and news folders.

Comment 93

[Magnus Melin [:mkmelin]]

Comment on attachment 8557379 [details] [diff] [review]
patch v3

Review of attachment 8557379 [details] [diff] [review]:
-----------------------------------------------------------------

Didn't we use to make the Total etc. columns reasonably sized. They not take up way too much space before you resize them. And why does the Name column have the dropmarker.

::: mail/base/content/folderPane.js
@@ +2273,5 @@
>    get level() {
>      return this._level;
>    },
>  
> +  getProperties: function ftvItem_getProperties(aColumn) {

function naming is no longer useful

@@ +2798,5 @@
> +     */
> +    addSummarizedPrefix: function(aValue) {
> +      if (!this.sumSubfolders)
> +        return aValue;
> +      else

no else after return

@@ +2833,5 @@
> +            .QueryInterface(Components.interfaces.nsIMsgFolder);
> +          let subSize = this.getFolderSize(subFolder);
> +          if (subSize == this.kUnknownSize)
> +            return subSize;
> +          else

no else after return

::: mail/base/content/messageWindow.js
@@ +550,5 @@
> +  let folderPaneCols_menuitem = document.getElementById('menu_showFolderPaneCols');
> +  if (folderPaneCols_menuitem)
> +    folderPaneCols_menuitem.setAttribute("hidden", "true");
> +
> +  folderPaneCols_menuitem = document.getElementById('appmenu_showFolderPaneCols');

nit: prefer double quotes wherewhere

Comment 94

[:aceman]

Attachment: patch v3.1

OK, I have removed the arrow on the Name column. I don't think we allow sorting of the folders in any mode. I also made the widths of the 3 new columns start at 50px by default. The user can then resize them. Also, they are not flexible now, so resizing the folderpane only flexes the Name column. Josiah, please see if 50px is a reasonable starting point on all platforms.

Comment 95

[Magnus Melin [:mkmelin]]

Comment on attachment 8560746 [details] [diff] [review]
patch v3.1

Review of attachment 8560746 [details] [diff] [review]:
-----------------------------------------------------------------

The context menu for it still needs to be fixed to show the options, like the thread pane one. Besides that, r=mkmelin

::: mail/base/content/folderPane.js
@@ +2810,5 @@
> +     * so that the property is initialized from the db.
> +     */
> +    fixNum: function(aNumber) {
> +      return (aNumber < 0 ? this.kUnknownSize :
> +              (aNumber == 0 ? "" : this.addSummarizedPrefix(aNumber)));

double ternaries are hard to read. 
maybe do the if (aNumber < -1) return his.kUnknownSize; first

::: mail/locales/en-US/chrome/messenger/messenger.properties
@@ +493,5 @@
> +## LOCALIZATION NOTE(summarizedValue):
> +## This string shows an indication that the value shown is actually a summary
> +## accumulated from all its subfolders.
> +## %S = summarized value from all subfolders
> +folderSummarizedValue=*%S

shouldn't the star be after the value?

Comment 96

[:aceman]

(In reply to Magnus Melin from comment #95)
> Comment on attachment 8560746 [details] [diff] [review]
> patch v3.1
> 
> Review of attachment 8560746 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> The context menu for it still needs to be fixed to show the options, like
> the thread pane one. Besides that, r=mkmelin
Which context menu? The "show columns" checkbox is in the main menu and the appmenu. Which other menu do you mean?

> ::: mail/base/content/folderPane.js
> @@ +2810,5 @@
> > +     * so that the property is initialized from the db.
> > +     */
> > +    fixNum: function(aNumber) {
> > +      return (aNumber < 0 ? this.kUnknownSize :
> > +              (aNumber == 0 ? "" : this.addSummarizedPrefix(aNumber)));
> 
> double ternaries are hard to read. 
> maybe do the if (aNumber < -1) return his.kUnknownSize; first
OK.

> ::: mail/locales/en-US/chrome/messenger/messenger.properties
> @@ +493,5 @@
> > +## LOCALIZATION NOTE(summarizedValue):
> > +## This string shows an indication that the value shown is actually a summary
> > +## accumulated from all its subfolders.
> > +## %S = summarized value from all subfolders
> > +folderSummarizedValue=*%S
> 
> shouldn't the star be after the value?
The string wouldn't align in the column as nicely in that case. MB in one row wouldn't be under MB in the previous row, etc.

Comment 97

[Magnus Melin [:mkmelin]]

(In reply to :aceman from comment #96)
> Which context menu? The "show columns" checkbox is in the main menu and the
> appmenu. Which other menu do you mean?

What you get when you right click the folder pane column header (Name).

Comment 98

[:aceman]

That menu shows options for the currently selected row (i.e. folder). No options for the columns or header itself. That seems intentional. So what do you mean? Do you want it to instead show options to toggle columns as in the message list pane?

Comment 99

[Magnus Melin [:mkmelin]]

Yes I think that's preferable. Context menus usually show options for a context, not for what is selected elsewhere.

Comment 100

[:aceman]

(In reply to Magnus Melin from comment #99)
> Yes I think that's preferable. Context menus usually show options for a
> context, not for what is selected elsewhere.
Yes, but it seems to be default behaviour of a <tree> to show the same context menu for the headers as for the data rows. In firefox, it even shows the context menu AND sorts the column, on the single right-click. What a mess :)

It seems the threadpane (message list) has made special hacks to override this. I am looking for that code.

Comment 101

[:aceman]

Attachment: patch v3.2

Is suppressing the context menu enough? :)

Comment 102

[Kent James (:rkent)]

I have one suggestion, having used this a bit while working on bug 1093217.

I find the ??? for no known value too intrusive. That usually means to me "Something was output that could not be interpreted" and looks like a bug. May I suggest a simple dash instead, "-"?

Otherwise, awesome! Let's get it into TB 38!

Comment 103

[Magnus Melin [:mkmelin]]

Comment on attachment 8561080 [details] [diff] [review]
patch v3.2

Review of attachment 8561080 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/folderPane.js
@@ +2204,5 @@
> +    return this.getText("folderNameCol");
> +  },
> +
> +  getText(aColName) {
> +      // Only show counts / total size of subtree if the pref is set,

this whole block seems to use 4 space indention. should be 2

@@ +2772,5 @@
>    }
>  }
>  
> +var gFolderStatsHelpers = {
> +    kUnknownSize: "???",

agreed "-" might be better. or just "?"

::: mail/base/content/mailContextMenus.js
@@ +297,5 @@
> +  // We do not want to show the context menu if clicking on the column headers.
> +  document.getElementById("folderTree").treeBoxObject
> +          .getCellAt(aEvent.clientX, aEvent.clientY, row, col, elt);
> +  if (row.value == -1)
> +    return false;

regarding this, for the thread pane it is done in CM_setTarget
http://mxr.mozilla.org/comm-central/source/mail/base/content/nsContextMenu.js#425

::: mail/base/content/mailWindowOverlay.js
@@ +710,5 @@
>  
>  /**
> + * Show or hide the headers of the folder pane columns.
> + */
> +function MsgToggleFolderPaneCols()

this is just used once and a one-liner, so please just inline it. we should get rid of such functions rather than add more of them

Comment 104

[:aceman]

Attachment: patch v3.3

OK, I think I solved the header context menu. I just used "after_start" to show the popup, instead of "before_start" that was used at the message list pane (I do not understand why it wanted the menu above the headers).

Josiah, there were some UI changes since your last review. Can you check them quickly so we can land this? It has all other reviews. Thanks.

Comment 105

[:aceman]

Attachment: patch v3.4

Forgot to remove the useless function.

Comment 106

[Kent James (:rkent)]

Josiah in comment 89 already gave a mostly positive response to this. It's now had plenty of review. Let's give Josiah another day to respond, but land it on 2/20 if we don't hear from him. He already said his availability is very low now.

Comment 107

[:aceman]

It is just that since his review some UI elements were changed (the - instead of ??? and the nonstandard (albeit better) context menu behaviour) so technically he should see it again. But yeah, feel free to land it anytime you wish. We can also land it and then polish it after that in new bug.

Comment 108

[:aceman]

OK, let's land it to get the strings in and polish it in new bugs.

Comment 109

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Pushed as http://hg.mozilla.org/comm-central/rev/6e2b817f4dcc

Comment 110

[Josiah Bruner [:jsbruner]]

Comment on attachment 8564731 [details] [diff] [review]
patch v3.4

Review of attachment 8564731 [details] [diff] [review]:
-----------------------------------------------------------------

Pretty good yeah.

Only two things I would suggest:
- Save the chosen columns when you switch back to Folder Pane mode, so that if the user goes back to Folder Pane Columns they won't have to re-enable the columns.
- Enable some columns by default, otherwise it's hard to notice that anything changed.

Both can be done in separate bugs.

Comment 111

[:aceman]

Thanks, filed bug 1135536 for those improvements.

Comment 112

[Charles]

(In reply to Magnus Melin from comment #93)
> Didn't we use to make the Total etc. columns reasonably sized.

****, wish I'd known this was being fixed...

I guess I'll go open a bug for making these column widths auto-adjust, so that they automatically resize themselves dynamically to the bare minimum needed to display the largest number, and no more...

Like how you can dbl-click on a column or row divider to auto resize the row or column to the size of the largest entry...

Comment 113

[Charles]

(In reply to Charles from comment #112)
> I guess I'll go open a bug for making these column widths auto-adjust, so
> that they automatically resize themselves dynamically to the bare minimum
> needed to display the largest number, and no more...

Done... see bug 1158597

Thanks again guys for reducing my Addon count by one... :)

Comment 114

[Wayne Mery (:wsmwk)]

Test in Moztrap https://moztrap.mozilla.org/manage/case/16265/
Let me know if anything is missing or incorrect.

Comment 115

[:aceman]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #114)
> Test in Moztrap https://moztrap.mozilla.org/manage/case/16265/
> Let me know if anything is missing or incorrect.

Thanks, looks fine now.

Comment 116

[km]

(In reply to Kent James (:rkent) from comment #86)
> Comment on attachment 8528640 [details] [diff] [review]
> patch v2
> 
> Yes I like it! Thanks for doing this.
> 
> I'm not completely sure about the star added to note that a folder is a
> summary. I like the idea of arking this (I've been fooled before by the lack
> of such a marker) but not sure about the star. I tried sigma and sigma
> blank, did not like them better. Underlining is another common nomenclature
> for a sum, perhaps that might work.
> 
> But I can live with the star.
> 
Correct me if I'm wrong, but the star seems to show up even when none of the child folders have unread messages, making it redundant as it is in effect a duplication of the arrow symbol on the left.

Comment 117

[lstout]

I have used the Extra Folder Columns add-on happily for several years.
I have just installed Thunderbird 38.1.0.  During installation, I was 
notified that this add-on was being disabled because it was           
incompatible.  I then found this bug discussion (464973), which       
indicates that the option for folder pane columns has been integrated 
into the Thunderbird base.  But the option is not visible!            
                                                                      
Eventually, on the description page for the old add-on, I found:      
                                                                      
"Yes, Extra Folder Columns is built in now, but in order to enable it 
you must modify with config editor the key                            
                                                                      
mail.folderpane.showColumns and set to true                           
                                                                      
ARB suggests to go to Options -> Layout -> click Folder Pane Columns  
but the option does not exist."                                       
                                                                      
I did this.  It had no immediate effect.  I restarted Thunderbird, and
then the folder pane column header appeared, with a column picker to  
add columns.  I am very pleased to have this feature back.            
                                                                      
In the hierarchy of feature discovery given in comment 75, the        
discoverability of this feature has been downgraded from              
                                                                      
4) not shown, you have to locate an addon to find that it even exists 
                                                                      
to                                                                    
                                                                      
5) enabled with a hidden preference.                                  
                                                                      
Was this the intention?

Comment 118

[Magnus Melin [:mkmelin]]

It's accessible via 
 - traditional menu bar: View | Layout | Folder Pane Columns
 - app-menu: Preferences | Layout | Folder Pane Columns

Comment 119

[Wayne Mery (:wsmwk)]

Also documented in the Thunderbird 38 what's new topic at https://support.mozilla.org/en-US/kb/new-thunderbird-38#w_expanded-folder-pane-columns  

Agreed, more discoverable would be desirable. As with most features.

Comment 120

[lstout]

(In reply to Magnus Melin from comment #118)
> It's accessible via 
>  - traditional menu bar: View | Layout | Folder Pane Columns
>  - app-menu: Preferences | Layout | Folder Pane Columns

Thank you, now I see it.
If you run with the traditional menu bar, the option is View | Layout | Folder Pane Columns .
Normally I don't run with the traditional menu bar.
In the application menu, under View, there is no Layout option.
I was getting ready to open a bug that in 38.1.0, the View / Layout option has been lost.
But thanks to your post, I now see that on the application menu, the option is under Options, not View:
Options | Layout | Folder Pane Columns .
(For me it is Options, not Preferences.)

Comment 121

[lstout]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #119)
> Also documented in the Thunderbird 38 what's new topic at
> https://support.mozilla.org/en-US/kb/new-thunderbird-38#w_expanded-folder-
> pane-columns  
> 
> Agreed, more discoverable would be desirable. As with most features.

Currently, the What's New item for "Expanded Folder Pane columns" says:

"In the folder pane (the list of folders on the left), you can now show expanded options (Unread, Total and Size) View|Layout|Folder Pane Columns."

This applies to the traditional menu bar.

Should I change it to:

"In the folder pane (the list of folders on the left), you can now show expanded options (Unread, Total and Size).  In the traditional menu bar, select View|Layout|Folder Pane Columns ; or in the application menu, select Options|Layout|Folder Pane Columns ."

But in the app-menu, do some users have "Preferences" instead of "Options", as indicated in Comment 118?  Or was that comment imprecise?

If somebody who actually knows what they are doing wants to make the update instead of me, that would be even better.

Comment 122

[Magnus Melin [:mkmelin]]

Windows uses "Options", Linux and Mac use "Preferences".

Comment 123

[lstout]

This is to note that after some further discussion, Wayne Mery clarified the item "Expanded Folder Pane columns" in the article "New in Thunderbird 38.0" on Jul 22, 2015 at 2:17:26 PM.