[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7] (release) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2pre) Gecko/20070123 SeaMonkey/1.1] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070122 SeaMonkey/1.5a] (nightly, 2007-01-22-08-trunk) (W2Ksp4) No bug. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070123 SeaMonkey/1.5a] (nightly, 2007-01-23-08-trunk) (W2Ksp4) In 3-pane window, Expand the header pane of a message: 'From' and 'To' addresses are missing their first left pixels. (as if aligned too much on the left, and recovered by their header name) 'Subject' and 'Date' display fine. I would hint at bug 333659 or bug 367504 !?

Same bug on the 'From' header, when the header pane is collapsed.

I think I've seen a similar report before, but it was quite some time ago. I can't locate the bug (if there even is one), but I have this in my userChrome.css for the suite: #addresses-box *|*.textbox-input { padding-left: 2pt !important; }

This collection of screen shots (each tiny, just showing the relevant area) shows messages that contain From, Sender, Reply-To, To, and CC headers. Observing them, we see that: - From is always clipped - Reply-To is always clipped - To is clipped in 3 out of 4 messages - Cc is clipped in 3 out or 4 messages (not the same set as To) - Sender is NEVER clipped Interestingly, the "G" in Gervase is clipped in one To, but not in another.

Correction. I wrote: > - Cc is clipped in 3 out or 4 messages (not the same set as To) That was wrong. CC is clipped in all 4 messages. In one case, the entire leading letter (ell) was clipped, turning lelteto into elteto. Because no part of the clipped letter was left exposed, the clipping wasn't so obvious.

Not really Core nor Backend, but mailWidgets.xml is used by both SM and TB.

I confirm missing pixels in "To:" in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070213 Mnenhy/0.7.5.0 SeaMonkey/1.5a

(In reply to comment #2) > I think I've seen a similar report before, but it was quite some time ago. > I can't locate the bug (if there even is one), but I have this in my > userChrome.css for the suite: > > #addresses-box *|*.textbox-input > { > padding-left: 2pt !important; > } > Mike, notice the blocking bug. A long project with many effects. If the above userChrome.css works for TB and Seamonkey, it might be worth it for nightly build users.

Mike's suggestion in comment 2 had no effect on the problem when I tried it.

I guess if the API is delivering the data in clipped format, nothing to do but wait for it to be corrected. One on the hazzards of navigating through the "Minefield" Besides, even if it could be masked, how would we know when it was really fixed.

I would have liked to have simply gone back and hidden comment 2, since that's a fix for a different problem. I apologize for posting it at all; I should have downloaded a current trunk build and checked before posting. I see this bug in both Seamonkey and Thunderbird on the trunk.

xref bug 372522

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070305 SeaMonkey/1.5a] (nightly) (W2Ksp4) Caused by bug 333659, fixed by bug 370588.