247833 - Long From/To push window content (incl. scrollbars) out of view

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P1)

Description

[Ben Bucksch (:BenB)]

If there's a long From address, it pushes the Attachments box out of the visible
window area, i.e. the box is cut off at the window border. The rest of the
window stays normal.
If there're long recipient (TO, CC, BCC) addresses, they also push the
attachments box out of the visible window area, but also do the same to the
other parts of the right half of the window, i.e. msg body, thread pane and
throbber.

With my fix for bug 9942, it just causes a horizontal scrollbar (incl. body) in
both cases.

Related to bug 91662, bug 9942, bug 56825.

Comment 1

[Ben Bucksch (:BenB)]

*** Bug 91662 has been marked as a duplicate of this bug. ***

Comment 2

[Peter Kirk]

An easy way to fix many instances of this (already mentioned in bug 91662
comment 282) is to adjust the parsing of address lines so that semicolon (as
well as comma currently recognised - semicolon is used in mail imported from
Outlook) is recognised as an address separator and so allows word wrap; or else
to allow word wrap at spaces within addresses at least if a single
(comma-separated) address is too long to fit in the window.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 251182 has been marked as a duplicate of this bug. ***

Comment 4

[Ben Bucksch (:BenB)]

I'll attach a fix for this. It is not perfect yet, but I am not sure I'll go
further and I think it's a large improvement over the current state.

Curently, the XUL is basically
<emails><email label="somebody m@com"/>
<text value=", "/><email label="Somebody else [e-mail]"/></emails>
where both emails and email are <xul:label>s with inherit="label" in the content.

What I wanted was to wrap like HTML inline, e.g. after "," or between "somebody"
and "else", whereever it makes sense. I couldn't figure out how to do it,
because XUL seems to think in boxes and I didn't know how to make XBL inherit
from HTML elements.

So, what I did was to put all the text into real text nodes (createTextNode, not
xul:text) inside html:spans, change the <emails> xul:label into xul:description
and make <email> inherit from xul:description (just using xul:description in
<contents> won't work). To do that, I had to change the setAttibutes on the XBL
element into properties. So, after exploding the XBL, I have
<xul:description><xul:description><html:span>somebody
m@com</html:span></xul:description>
<html:span>, </html:span><xul:description><html:span>Somebody else
[e-mail]</html:span></xul:description></xul:description>

This works, with a caveat: Each <xul:description> is still treated as box, and
it wraps as a whole, while its contents wrap independently inside that box. So,
you end up with something like
Somebody,
else
[e-mail]
(note the position of comma, it's supposed to be after the email address)
because the xul:descr is a rectangular box, "Somebody else [e-mail]" wraps inside
it, and xUL:descrs as a whole and the comma wrap in the parent xul:descr.

I tried to make allpart of the same wrapping by inheriting from html:a
(extends="html:a"), but that appearantly didn't work. Any hints welcome.

Also, the code has a hidden XUL element which is never displayed, but used to
store the values. I tried to change that into XBL fields, but that didn't work.
I'll attach that version (as "version 1") anyways in case somebody points me to
my error. Alas, the hidden element is not nice, but works.

So, version 2 is my current state, which I think should go into the tree. mcott,
please review. Thanks.

Comment 5

[Ben Bucksch (:BenB)]

Attachment: Fix, version 1, broken

Comment 6

[Ben Bucksch (:BenB)]

Attachment: Fix, version 2

Comment 7

[Ben Bucksch (:BenB)]

Comment on attachment 157384 [details] [diff] [review]
Fix, version 2

I just discovered problnems during viewing *normal* mails with this patch.
Revoking review request.

Comment 8

[Ben Bucksch (:BenB)]

Attachment: Fix, version 3

This fixes all remaining problems, apart from a minor one:
The header pane doesn't shrink to minimal size. If you view a msg with only one
recipient, the To part is 1 line high. If you view one with 10 recipients, it's
3 lines high (the rest only after expansion). If you then view the first msg
again, it stays 3 lines high, it doesn't go back to 1 line. Because it never
goes more than 3 lines (2 empty ones), I don't consider that critical.

Comment 9

[Ben Bucksch (:BenB)]

Comment on attachment 157997 [details] [diff] [review]
Fix, version 3

The "header pane doesn't shrink to minimal size" is actually worse. It seem
slike the header pane reserves 3-4 times the vertical space that it needed for
one email address. If that were 2 lines, because it wrapped, I get 6 empty
lines. No good.

Comment 10

[Jeff Fried]

I cannot tell from the existing notes if it is clear that under OSX the scroll
for the message body disappears when this problem occurs under 1.7.2.

Comment 11

[Mike Cowperthwaite]

xref bug 118513

Comment 12

[Frank Wein [:mcsmurf]]

*** Bug 278150 has been marked as a duplicate of this bug. ***

Comment 13

[Ben Bucksch (:BenB)]

*** Bug 118513 has been marked as a duplicate of this bug. ***

Comment 14

[Ben Bucksch (:BenB)]

Yes, this is the bug which makes scrollbars disappear. Adapting SUMMARY.

Comment 15

[Heather Hollingsworth]

can't acces email through moxilla mail

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 285248 has been marked as a duplicate of this bug. ***

Comment 17

[Mike Cowperthwaite]

*** Bug 281858 has been marked as a duplicate of this bug. ***

Comment 18

[simon annear]

Hi Ben

I'm not able to help much with the coding - but is there anything else you need
assistance with to get this bug resolved?

removing target milestone as 1.8a4 has been and gone :)

Simon

Comment 19

[Ben Bucksch (:BenB)]

Not that I'd know of at the moment.

Comment 20

[OstGote!]

*** Bug 291166 has been marked as a duplicate of this bug. ***

Comment 21

[Julien Cervelle]

*** Bug 296353 has been marked as a duplicate of this bug. ***

Comment 22

[Philip Lunn]

Still the case in 1.5 beta 2

Comment 23

[Ray Booysen]

Per Comment #22

Can you see this in Thunderbird too?

Comment 24

[Lucius Chiaraviglio]

(In reply to comment #23)
> Can you see this in Thunderbird too?

Still a problem in Thunderbird 1.5 Beta 2.

Comment 25

[Eyal Rozenberg]

This is quite a high-visibility bug, which has certainly not gotten enough attention. One can't even work around it, except by Select All , Copy & Paste into an external editor. It is not specific to seamonkey/mozilla suite - it appears with TB, all the way upto 1.5.0.4 .  Ben Bucksch: Please un-bitrot the latest patch, and try to explain in words what the problem is and how you have fixed it (because maybe I'd like to have a look at it myself).

Since TB is the main mozilla mail client project, I'm changing the component.

Comment 26

[Eyal Rozenberg]

Ben: Have you considered the possibility of having an <html:p> element with <html:a>'s within it for the e-mails, and text nodes for the , 's?

Comment 27

[Mike Cowperthwaite]

(In reply to comment #25)
> One can't even work around it, except by Select All , Copy & Paste
> into an external editor. 

Assuming you're talking about the problem of message content getting truncated because the wrap-column ends up beyond the window edge: there is a workaround.  In userContent.css, add these lines:

.moz-text-flowed { max-width: 90ch !important }
.moz-text-html { max-width: 42em !important }

This forces the wrap point to a particular position, rather than having it follow the window edge.  I use these all the time anyway, because when the text fills the entire width of the message pane (which I normally have sized at 
about 120 plain-text chars), it's too wide to read comfortably.

You can add a similar rule for .moz-text-plain (non-f=f plain text), altho the linebreaking that may result 
from that will look odd, with alternating long and short lines, not unlike the
text I'm typing in here.

Comment 28

[Felix Miata]

This was filed as a suite bug, and it still is a suite bug. If TB needs a bug like it, file one.

Comment 29

[Eyal Rozenberg]

(In reply to comment #28)
Ok.

(In reply to comment #27)
So it's not really a workaround for plain text mail... certainly not something I would have my computer-illiterate friends do :-(

But let's not split hairs; regardless of the above, I think this a major bug in the absolute core functionality of tb and deserves more attention. And if I didn't have a midterm in Galois theory tomorrow I might try to give it that attention myself...

Comment 30

[Peter Lairo]

Just in case someone didn't notice, bug 340327 has been filed to cover the Thunderbird side of this bug.

Comment 31

[tqh20178]

Can I get a copy of Firefox 1.01?  It didn't have this problem.

Comment 32

[Mike Cowperthwaite]

There are so many different bugs about the header panel's various issues...
Bug 240313 requests a CSS change for the envelope panel which was designed to fix bug 223132.  Bug 240313 comment 12 notes that a variation of this hack behaves even better with nightly builds of TB 2.0.  Either variation adds a horizontal scrollbar to the envelope which prevents the message-body from expanding beyond the window edge when there's a long address in the headers.


(In reply to comment #31)
> Can I get a copy of Firefox 1.01?  It didn't have this problem.

No, it didn't: Firefox doesn't display mail messages.  Thunderbird 1.0.x does exhibit the problem discussed in this bug.  However, if you care to test this for yourself, older releases are available at
  ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases

Comment 33

[Felix Miata]

*** Bug 359489 has been marked as a duplicate of this bug. ***

Comment 34

[Eyal Rozenberg]

See the testcase I attached in bug 340327:
https://bugzilla.mozilla.org/attachment.cgi?id=247201

SM trunk builds continue to exhibit the bug with this testcase. Like I wrote in bug 340327, however, I'm not sure about whether you can get this bug with plain-ascii names in the To or CC field.

Comment 35

[Ben Bucksch (:BenB)]

Comment on attachment 157997 [details] [diff] [review]
Fix, version 3

mscott, I just saw that this patch is still here, aparantly ready for review. See comment 8 (and earlier ones).

The patch is old and probably bitrotten, I haven't even looked at it since a long time, but I'd like to know if you think this is good and worth resurrecting.

Comment 36

[Mike Cowperthwaite]

The suite has already taken on the proven fixes from TB bug 335973.  There is still an issue with Seamonkey due the attachment box being in the envelope panel, but I think you need to completely revisit this patch.

Comment 37

[Ben Bucksch (:BenB)]

What does that do? What's described in bug 335973 comment 8?

From comment 4, this patch here tries
> to wrap like HTML inline, e.g. after "," or between "somebody" and "else",
> whereever it makes sense.

Comment 38

[Mike Cowperthwaite]

Address lists are wrapped between addresses.  (Not perfectly, as a wrap will occur immediately before a comma.)  Single addresses that are too long are truncated.  A twisty is added when wrapping or truncating (and, unfortunately, sometimes when there's plenty of room for all the addresses).  

Works pretty well, modulo the parenthetical notes here; but the attachment box, message-body scrollbar, and (this is new) the thread-pane's right edge get pushed out when a long single address (or multi-address lines that fail to wrap) get expanded by opening the twisty.  This is in SM 1.1 as well as trunk.

Comment 39

[Ben Bucksch (:BenB)]

> Address lists are wrapped between addresses.

Right. The hard thing in *this* patch was that they wrap *inside* the addresses. (This was hard, because email addresses are currently XBL bindings, so XUL inside <html>/<description>, and thus couldn't wrap inside in current Gecko.)

The usecase I had was something like:
Herbert A. Hulbert-Schmidt-Freuenheuser <[e-mail]>
OK, extreme example, but you see what I mean: long name, name again in email address, and long domain. For one of my customers, that's a very common case.

Comment 40

[Nelson Bolyard (seldom reads bugmail)]

This problem is still alive and well in SM trunk in April 2008.
There's a 3.5 year old patch still awaiting review.

Comment 41

[[e-mail]]

(In reply to comment #40)
> This problem is still alive and well in SM trunk in April 2008.
> There's a 3.5 year old patch still awaiting review.
Which sadly has probably bitrotted significantly.

I would like to point out that bug 335973 changed the problem slightly so that
a) if the long address is the only address then it is simply truncated
b) if the long address is one of several then the corrupt display only occurs when you expand the addresses

Comment 42

[Ian Neal]

This is a nice to have but we would not block release of 2.0a1 on this

Comment 43

[Wayne Mery (:wsmwk)]

Comment on attachment 157997 [details] [diff] [review]
Fix, version 3

mscott no longer actively reviewing, so canceling review

Comment 44

[javgal]

jopkjpoijoj/oijoijoj

Comment 45

[Yaniv Kaul]

Not sure if it's the same bug, as I'm asking for a change: the Headers view, even in normal view, are not utilizing the display space properly - they are one below the other, instead of some being next to each other. All the normal view shows is From, Sender, Reply-To, Date and To - why not have some of them next to each other? This, especially in the today's popular wide screens, would add more space to more visible lines (I'd say ~3) in the email message.

Comment 46

[Ben Bucksch (:BenB)]

The problem I described in comment 8 and 9, which is why I haven't pushed for Fix v3 to be reviewed/checked-in, is IIRC very similar to the problem I encounter in bug 489609.

Comment 47

[Ben Bucksch (:BenB)]

That problem seems to have gone away, at least for Thunderbird. Maybe this is feasible now.

Comment 48

[:Hb]

FIXED for address headers. Because long subjects are not fully shown I filled bug 528434.