If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Some email addresses are truncated in headers

RESOLVED FIXED in Thunderbird 3.3a1

Status

Thunderbird
Message Reader UI
--
minor
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Frédéric Buclin, Assigned: rsx11m)

Tracking

Trunk
Thunderbird 3.3a1
Dependency tree / graph
Bug Flags:
in-litmus +

Thunderbird Tracking Flags

(thunderbird3.1 .7-fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Created attachment 480199 [details]
screenshot

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

Updated

7 years ago
Blocks: 550487
(Assignee)

Comment 1

7 years ago
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.
(Assignee)

Updated

7 years ago
OS: Linux → All
Hardware: x86 → All
Version: 3.1 → Trunk
(Assignee)

Comment 2

7 years ago
Created attachment 481552 [details] [diff] [review]
Simple fix for option (1)

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".
Attachment #481552 - Flags: ui-review?(clarkbw)
Comment on attachment 481552 [details] [diff] [review]
Simple fix for option (1)

looks like the right option to me. simple and works
Attachment #481552 - Flags: ui-review?(clarkbw) → ui-review+
(Assignee)

Comment 4

7 years ago
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.
Attachment #481552 - Flags: review?(bwinton)
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.
Attachment #481552 - Flags: review+
(Assignee)

Comment 6

7 years ago
Thanks - that was probably a new record in reviewing speed.  :-)

Push on trunk, please.
Assignee: nobody → rsx11m.pub
Status: NEW → ASSIGNED
Depends on: 567062
Keywords: checkin-needed
Whiteboard: [c-n: comm-central]
(Assignee)

Updated

7 years ago
Attachment #481552 - Flags: review?(bwinton)
Checked in: http://hg.mozilla.org/comm-central/rev/9dc286cb2905
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [c-n: comm-central]
Target Milestone: --- → Thunderbird 3.3a1
(Assignee)

Updated

7 years ago
Flags: in-litmus?(ludovic)
13686
Flags: in-litmus?(ludovic) → in-litmus+
(Assignee)

Comment 9

7 years ago
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.
Attachment #481552 - Flags: approval-thunderbird3.1.6?
(Assignee)

Comment 10

7 years ago
(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)
(Assignee)

Comment 11

7 years ago
Thanks, that's better.
Attachment #481552 - Flags: approval-thunderbird3.1.7? → approval-thunderbird3.1.7+
Checked into 1.9.2: http://hg.mozilla.org/releases/comm-1.9.2/rev/42cc6bf2533e
status-thunderbird3.1: --- → .7-fixed
You need to log in before you can comment on or make changes to this bug.