Long lists of email addresses are truncated when viewing an email, see the screenshot, and notice what happened to newlib@sourceware.org.

To some extent this is similar to bug 567062, but coming from the other end. The last address of the visible part in the singleline display is to be shown sliding underneath the "more" button, which works fine as long as there are actually more addresses following. In this special case, the last address has more than 30px visible and is therefore shown. However, there is no "i+1"-th address, consequently the list ends here and the "more" button isn't shown. The suggested workaround would probably be to simply increase the window width so that the full address becomes visible, but that's not a general solution. Two options I'd see to resolve this: (1) always hide the very last address if it doesn't fit into the header for the singleline case, which may leave a gap larger than 30px but would allow to expand the last address with a "1 more" button; or (2), allow the last address to be truncated but display the "more" anyway to allow a full expansion as necessary, which may look funny if you see some "0 more" label on the button (effectively "0.5 more" rather). Options (1) would imply a straight-forward extension of the condition revised in bug 567062, adding another component to always hide the last address, where (2) may require some more thinking how to do it right.

This patch introduces another special case for the last address in the singleline case. It does not affect any address other than the last one, and does not change anything for the preference (n=0) or (n>1) cases. Steps for testing the patch, mailnews.headers.show_n_lines_before_more=1: 1. Find an e-mail with enough recipients to just fit into a single line; 2. drag the right window border so that "other actions" slightly truncates the n-th address (a 30px threshold applies to account for the "more"); 3. go to a different message and come back (due to bug 560698); 4. now you should see the the last address hidden with "1 more"; 5. drag the right border to the left so that more than 30 pixels remain to the last-but-one address (bug 567062 should still apply here); 6. go to a different message and come back again; 7. now you should see part only of the n-1 address and "1 more"; 8. reducing further below 30px should hide n-1 as well, showing "2 more".

Comment on attachment 481552 [details] [diff] [review] Simple fix for option (1) looks like the right option to me. simple and works

Comment on attachment 481552 [details] [diff] [review] Simple fix for option (1) Thanks - Blake, whenever you get a chance for the review. Similar to bug 567062, I don't see a way how to test this automatically. Thus, the litmus test at https://litmus.mozilla.org/show_test.cgi?id=12638 either could be extended by the steps in comment #2, or a complementary test added to the list reflecting the steps for testing.

Comment on attachment 481552 [details] [diff] [review] Simple fix for option (1) Pre-emptive review! (I did 10 of the last 15 reviews to this file, so I figured you'ld probably ask me when you got around to it. ;) I agree with Bryan. Simple, and it works. r=me. Later, Blake.

Thanks - that was probably a new record in reviewing speed. :-) Push on trunk, please.

Checked in: http://hg.mozilla.org/comm-central/rev/9dc286cb2905

13686

Comment on attachment 481552 [details] [diff] [review] Simple fix for option (1) This works fine on today's trunk nightly and no test failures due to this patch. I have been using a patched 20101013 Thunderbird/3.1.5 (build3) release candidate for a while without seeing any issues in the various modes. Requesting branch approval for 3.1.6 as this appears to be low risk and safe.

(In reply to comment #8) > https://litmus.mozilla.org/show_test.cgi?id=13686 Ludo, my laundry list in comment #2 may have been a bit too long, but I think the current litmus test is a bit ambiguous and hard to verify. Proposed extensions: > Steps to Perform: > 1. Create a new email > 2. add a bunch of recipient to have >+ so that it fills one line when displayed, > including yours. I recommend using yo@invalid.com to fill in the blanks > 3. send the email >+ or save as draft >+ 4. When viewing the message, vary the window size to be just a bit larger > or smaller than needed >+ 5. Go to a different message and come back to see the change > Expected Results: > Make sure the last addess is not cut off when the email is displayed. >- (on the first line) // that should be obvious with singleline setting >+ You should either see the last address in full or "1 more" instead Also, I think this should be "display" rather than "composition" subgroup: > Mail composition (1731)

Thanks, that's better.

Checked into 1.9.2: http://hg.mozilla.org/releases/comm-1.9.2/rev/42cc6bf2533e