Is Bug 550487 fixed in TB 3.1 Beta2?

[mad.engineer]

I just installed TB 3.1 Beta2 on Windows:
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.5pre) Gecko/20100430 Thunderbird/3.1b2

I looked at the full list of bugs fixed for both 3.1 Beta 1 and 2, but did not see: "Bug 550487 - Show n lines of addresses in To/CC/BCC headers" as being fixed in any of these releases, even though the status show as:
"Status: RESOLVED FIXED"
"status-thunderbird3.1: beta2-fixed"

Any one know whether it got fixed in Beta 2 or will be in RC1? Thanks

[rsx11m]

Well, it was checked in for beta 2 but isn't quite fixed yet. I didn't have the time to test it in detail, but see already some bugs (such as the last address being cut off if it's just close but not beyond the "more" threshold, header line is not wrapping, etc.). I'm afraid that there will be a couple of follow-up bugs necessary, if they haven't been filed yet.

[mad.engineer]

I guess then we'll have to rely on your mailWidget.xml hack in 3.1 as well if this don't get fixed by that time. Thanks

[rsx11m]

I've just filed bug 565209, the mailnews.headers.show_n_lines_before_more preference doesn't work as intended.

Btw: The 3.0 hack will no longer work in 3.1, the entire code has been substantially rewritten (again).

[rsx11m]

The following workaround in userChrome.css (no more jar-file hacking!) allows the wrapping of the header lines for mailnews.headers.show_n_lines_before_more with more than 1 (I'm still seeing more lines displayed than there should be, couldn't figure out where those are coming from):

Code: Select all

.headerValueBox > .headerValue {
  white-space: normal !important;
}

.headerValueBox {
  overflow: visible !important;
}

[rsx11m]

Update: I've posted a patch to bug 565209 for review, which corrects the line-counting algorithm that was introduced in bug 550487 and allows the headers to wrap for the n>1 case. It works fine for me on Windows and Linux, of course performance goes a bit down (depending on your processor) if you have a large n and many "to" or "cc" addresses need to be expanded to fill those lines. It's different from the click-"more" case (bug 560695) as the reflow still has to occur with each address added while figuring out if n lines have been filled already.

After the initial attempt to just allow the lines to expand with the wrong line count apparently didn't quite meet the enthusiasm of the developers (mainly because it involved disabling part of a test which would do its job and throw an error based on the line-count mismatch), this more comprehensive fix will hopefully make it. Maybe not for the initial 3.1 release (this depends on how quick the reviews/approval go and if there are further release candidates - RC1 is almost out already), but at least then for a 3.1.1 "dot" release. Let's see, just keep watching the bug report.

[mad.engineer]

rsx11m, Thanks for the heads up that the old jar file hack will not work in 3.1. Just so that I understand it correctly by changing the mailnews.headers.show_n_lines_before_more with more than 1 and adding the above code to userChrome.css will work the same way as the old jar file hack worked?. Till your permanent patch gets included.

[rsx11m]

Yes, you change the preference to some value larger than 1 and modify (or create) the userChrome.css file in your profile. Once a version of that patch got checked in, you should no longer need the userChrome.css hack and the number of lines shown for the headers should be correct.

[mad.engineer]

Thanks. Keep us posted on the progress if/when your patch makes it to the final 3.1 version.

[mad.engineer]

Do you know why mailnews.headers.show_n_lines_before_more is kept as a hidden feature and not exposed in the UI?. Thanks

[rsx11m]

It's definitely too late now for any UI in the TB 3.1 preferences, but bug 456596 is still open which proposed such a UI for the n-address case (now we have an n-line preference, so slightly different). I think it got dropped (intentionally or not) when the focus moved on bug 550487.

Let's wait for the backend fixes to land and then we can revisit the question of a preferences UI. Unfortunately, this keeps dragging on. The fix won't be taken for 3.1 RC2 after first a ui-review was requested, which didn't happen last week, and now the release drivers decided for some "baking" time on trunk (i.e., checking it in for 3.2a1pre to see if it works out there) before this can be included in a 3.1.x minor update. So, this will require a bit more patience...

[rsx11m]

The patch was checked in for trunk (TB 3.2a1pre) today. I don't know how long it will have to be baking, but will just flag it for 3.1 approval after a few days.

[mad.engineer]

TB 3.2a1pre -> Does that mean that the patch will be included in 3.2 and not 3.1?. Also, if it indeed makes it to 3.1, do we still need to use your userChrome.css code listed above along with mailnews.headers.show_n_lines_before_more OR just changing the hidden pref alone would be sufficient?. Thanks

[rsx11m]

That's what the "baking" period is all about. The 3.1 branch is where the current releases (3.1, then 3.1.1, etc.) come from, whereas development is performed on the "trunk" (currently numbered 3.2 as the next higher number, and which corresponds to the Minefield builds in the Firefox world). If the release drivers consider a modification of higher risk than they feel comfortable with, especially given that the release candidates are in progress already, the fix goes on this trunk first. There it can be tested in the nightly builds, and if nobody detects any errors, it can go onto the release branches.

I'll wait until after the weekend before requesting branch approval, if the current 3.1 RC2 becomes the actual 3.1 release, the fix will hopefully go into 3.1.1 then and it's only a formality.

[mad.engineer]

Thanks for the clarification. Would we still need to use:

.headerValueBox > .headerValue {
white-space: normal !important;
}

.headerValueBox {
overflow: visible !important;
}

in userChrome.css ? Thanks