Display all To:/Cc: by default

[rsx11m]

In general, using a large n will work just fine without any userC*.whatever hacks once 3.1.1 is released with those patches included, just potentially slow depending on the number of addresses that need to be shown. I'm not sure when the 3.1.1-approval queue will be worked on by the person in charge (Mark = standard8, he should be back this weekend), but it shouldn't take too long any more given the intended mid/late-July release date.

As an update, the developers have refused to take the two patches for 3.1.1, even though four other patches have been included for the second build. I don't understand that reasoning, given that the main patch has baked for a month now on trunk. Anyway, you'll have to keep your userChrome.css entries as they are for now also after the 3.1.1 update, and let's wait for 3.1.2 then.

No movement on the patch in bug 576611 for the "all" case yet.

[Guest]

rsx11m, Thanks for the heads up. I'd suggest that you update http://kb.mozillazine.org/Thunderbird_3 ... .22_Button with the above info so that others who may be interested know that the fix is not coming in 3.1.1

[rsx11m]

According to the comment, the patches are supposed to be checked in immediately after 3.1.1 is taken care of. Thus, the next 3.1.2pre nightly build should have the fix on top of what constitutes 3.1.1, and interested users could install just that nightly build to get the complete fix ahead of the official 3.1.2 release.

[Neville]

Thanks for keeping us informed.

My interest is in the 'all' version so any news about this would be welcome.

[rsx11m]

For always showing "all" in Tb 3.1, the userChrome.xml workaround in viewtopic.php?p=9570923#p9570923 should remain the same even after the patches were checked in for 3.1.2.

[Neville]

Thanks. Do you expect an 'all' option to be adopted by TB in future.

[rsx11m]

It depends on the result of the ui-review, but that specific developer appears to be not very active right now (at least not with respect to reviews).

[rsx11m]

The first review on the user experience was just granted, technical review is pending now on the "all" (n=0) patch in #576611.

[Neville]

Thanks.

I saw all the activity on https://bugzilla.mozilla.org/show_bug.cgi?id=576611 earlier and was surprised how quickly things appeared to be moving.

Do you know of anybody who might take an interest in the following? viewtopic.php?f=39&t=1947287

[rsx11m]

Sorry, no clue, but there seems to be quite a bit of feedback in that bug report, so stay optimistic. I usually have the message pane open at all times, thus wouldn't notice if it also happens on Windows or Linux (but I think there were cases as well).

I saw all the activity ... and was surprised how quickly things appeared to be moving.

Me too. The patch yet has to pass the technical review though, but the basic message is "yes, we want that".

[rsx11m]

Instructions for TB 3.1.3pre (working preference)

The patches have been approved and checked in yesterday for the regular Thunderbird 3.1 branch as well, thus they are finally available in regular builds! They won't be visible in the official releases until 3.1.3 though, due early September.

If you don't want to wait that long but use the preference already now, and without any userChrome.css hacks (you would still need the userChrome.xml workaround for showing all addresses when opening a message), you can download and install the August 3 nightly builds from the following links:

Mozilla/5.0 (Windows; U; platform; en-US; rv:1.9.2.9pre) Gecko/20100803 Lanikai/3.1.3pre

• 20100803003128 (Windows)
• 20100803031711 (Mac OSX)
• 20100803002441 (Linux)

Disclaimer: "Nightly builds - even on the release branch - haven't undergone any QA and may therefore contain bugs." This is basically the upcoming 3.1.2 release plus a couple of patches which they didn't want to take quite yet for that update.

If you install the nightly, it will identify itself as "Lanikai" rather than Thunderbird, that's the code name for those builds. Make sure to disable automatic updates, otherwise you'll receive daily patches of the current changes on the release versions. Once 3.1.3 comes out, install it to get back on the regular release channel (and don't forget to reactivate updates at that time). Enjoy!

[Guest]

This is good news. Thanks for all your work on this front. So if I understand correctly, for those who want to see all the addresses listed regardless of the preference value, they would still need to keep the .xml method as listed at: viewtopic.php?f=39&t=546398&start=45 ?.

And for those who don't want to see all the addresses, but use the preference value instead, they would need to remove all the above .xml code to make it work (in 3.1.3 and later only) ?

I think once 3.1.3 becomes available, you should update the section http://kb.mozillazine.org/Thunderbird_3 ... .22_Button to clarify both methods since it may be easy for others to get confused if not already

[rsx11m]

You have currently three options:

1. If you want the preference but don't want to use a nightly build, stay on the current releases and use the userChrome.css code shown in viewtopic.php?p=9341845#p9341845 (the counts may be inaccurate).
2. If you want a functioning preference for n lines, switch to the nightly build as explained above and remove the userChrome.css entries, nothing else to do.
3. If you don't care about the number of lines shown and just want to always see all addresses, use the CSS and XML code given in viewtopic.php?p=9570923#p9570923 along with the release builds (this will apply even after 3.1.3, assuming that bug 576611 will come with 3.2/3.3/3.5 only).

This hopefully clears up what is needed for which use case, I've also updated the KB article with a link to the post above.

[Neville]

Am I correct in thinking that setting n=0 will invoke 'all' from 3.1.3 onwards without the CSS and XML code? Will this be as efficient (ie as fast) as the CSS/XML 'all' only method?

[rsx11m]

No, the patches only cover the n=1 and n>1 cases, n=0 is handled in bug 576611 and yet has to be checked in (it's awaiting feedback from dmose right now). Even then, it would only be available on the current 3.2a1pre "trunk" builds. Thus, you'll need the CSS/XML workaround still for the fast-all display even after 3.1.3 is released.