91662 - Long Strings in Mail/News Header causes Folder Pane to Resize and/or Jiggle

Status: VERIFIED DUPLICATE of bug 247833

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

Description

[(not reading, please use [e-mail] instead)]

emails with long subjects make thread pane go wild

sample message coming up.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: make a local folder with this email to see the problem

Comment 2

[(not reading, please use [e-mail] instead)]

note, it wasn't until I loaded the message that the thread pane went wild.

Comment 3

[(not reading, please use [e-mail] instead)]

updating summary.

I'm not sure yet if it is long subjects, that particular subject, or what.

my guess it is an outliner bug, but I'll investigate first.

Comment 4

[laurel]

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

Comment 5

[laurel]

There are a few older bugs about this, I'll duplicate them to this one since
Seth is working on it... 83503 85106 76793

Comment 6

[laurel]

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

Comment 7

[laurel]

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

Comment 8

[(not reading, please use [e-mail] instead)]

so when the email with a long subject is selected, this happens.

if it isn't selected, this doesn't happen.

the place to start is the outliner code that paints the text (or images) and
checks if the row is selected or not.

Comment 9

[Dawn Endico]

Note that long "to" fields also break. (see duplicate Bug 85106)


I see what's happening. The culprit here is the message pane's toolbar. Long
subjects normally wrap at the right edge of the window. If the subject contains
no whitespace (or contains an extremely long word) then Mozilla behaves as if
its right edge was actually at the right edge of this extremely long string
except that it doesn't go to the trouble of resizing the window. 

In the test case that I am about to attach notice that:

- the throbber disappears
- the stuff in the right side of the status bar disapears (eg. Unread: Total)
- on a high res screen not all the fields disappear unless you resize the window
  to be pretty small. If you widen up the window all the way, the entire subject
  can display and everything looks normal.
- the paragraph wraps at the end of the subject line. If the entire subject
  isn't displayed then the right end of the paragraph is also truncated.
- as you widen the window the content of the status bar and the throbber slowly
  return to view from the right.

Comment 10

[Dawn Endico]

Attachment: better test case

Comment 11

[Robert Ginda]

isn't this just a missing crop="right" attribute?

Comment 12

[Dawn Endico]

it seems like crop="right" will crop the subject even if it has normal
whitespace and can wrap properly. Doing that would be fairly suboptimal,
although its
probably better than making the thread pane unusable. 

rob says that in chatzilla he adds 0px images to long strings to make them 
wrappable. 

Comment 13

[Håkan Waara]

I think bug 83503 is a dup.

Comment 14

[Eric Hedström]

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

Comment 15

[Eric Hedström]

As noted in bug 83503, long cc: addresses (with or without spaces) also make
this show up. It's especially annoying if the message has file attachments
because the whole attachment list falls off the right side of the window.

Comment 16

[Dawn Endico]

Erich has a good point. This bug also make the scrollbar in the message pane
go away. My test case isn't long enough to demonstrate that. Between missing
scroll bars and missing attachment windows this bug makes mozilla quite unusable
for certain messages. It seems like some people with low res screens could find
this happening with most or all of their mail. Adding dataloss keyword.


This bug occurs with both modern and classic.

Comment 17

[(not reading, please use [e-mail] instead)]

stepping through nsOutlinerBodyFrame.cpp, we are cropping right.

if you don't define a crop style, we crop right.

you can tell we are cropping because in most cases "..." is appended to the end 
of large text cells.

it's just these monster subjects that are horking us.

I'm back in the debugger, trying to figure it out.

Comment 18

[(not reading, please use [e-mail] instead)]

interesting:  if I collapse the message pane, selecting the "evil" message 
doesn't cause the thread pane to go wild.

Comment 19

[(not reading, please use [e-mail] instead)]

this sounds wacky, but I think it has something to do with the subject in the 
message pane.

If I toggle to the collapsed view (in the message pane) it doesn't happen 
either.

Comment 20

[(not reading, please use [e-mail] instead)]

I'm guessing that the two share a box, and so when the subject in the message 
pane gets huge, it stretches the box associated with the thread pane.

getting close here...

Comment 21

[(not reading, please use [e-mail] instead)]

Attachment: a fix, need mscott to review

Comment 22

[(not reading, please use [e-mail] instead)]

taking with mscott, this is not the right fix.

we use an <html> tag and flex=1 so that large subjects will wrap.

for wrapping to occur, there needs to be spaces in the subject.

by removing flex=1, I've made it so subjects with spaces won't wrap, which is bad.

so there are two parts of this bug.

1)  make it so long subjects without spaces don't make the thread pane go wild
2)  make it so long subjects without spaces don't push the attachment tree
off screen.

Comment 23

[Eric Hedström]

Don't forget, long email addresses in the message header cause the same problem.

If you consider that a different bug, please reopen bug 83503.

Comment 24

[Scott Davis]

It seems that
  1) long subjects get wrapped
  2) long From: addresses get clipped (below the beginning of the word Attachments)
  3) long To: addresses push the attachments box to the right.

As a result of 3), the virtual width of the entire panel is extended to the
width of the header block, including the attachments list. This means
  a) attachments list may not be visible
  b) scroll bar for message list is outside the window, along with some columns
from the right side of this display
  c) vertical scrollbar for message body is outside the window, making it easy
to fail to notice there is more message below the visible pane
  d) Message body is wrapped at the (wide) virtual window size, meaning some
text is outside the window, but there is no horizontal scrollbar.

These comments are made against nightly build 2001072910, Solaris/SPARC, but it
has been about like this for over a month.

Comment 25

[(not reading, please use [e-mail] instead)]

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

Comment 26

[(not reading, please use [e-mail] instead)]

I'd love to fix this for 0.9.4, but it probably won't happen.

at one point dbaron suggested looking into why the min-width on the header box 
wasn't doing the trick.

Comment 27

[(not reading, please use [e-mail] instead)]

slide to 0.9.5

Comment 28

[Dawn Endico]

This isn't as rare as you might think.

Now that i know what's happening, with I'm seeing this probem 
with some regularity. Not extreme examples like the test case,
but just enough warpage to push the scrollbars off the edge of
the screen and make the window unusable.

I recently saw a message with an attachment and long, but not
absurdly long From address. something like...

"[e-mail]"<[e-mail]>

The longish email address was used as the "real name",
in quotes and was followed by the a repeat of the address,
with no space in between. This not extrordinarily long address
didn't fit between the left edge of the screen and the attachment
box so the message pane was warped and the message's scrollbar
was pushed off the edge. 

Next time i'll try not to be in a hurry and save it to attach
as a test case.

Comment 29

[Håkan Waara]

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

Comment 30

[Tuukka Tolvanen (sp3000)]

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

Comment 31

[Peter Trudelle]

I see this frequently; it makes the mail window seem fundamentally broken.

Comment 32

[(not reading, please use [e-mail] instead)]

Comment on attachment 43231 [details] [diff] [review]
a fix, need mscott to review

bad patch.

Comment 33

[(not reading, please use [e-mail] instead)]

moving out.

Comment 34

[Ben Bucksch (:BenB)]

Looks like this is a dup if bug 47786. Marking so. Please excuse me and reopen,
if I overlooked something.

*** This bug has been marked as a duplicate of 47786 ***

Comment 35

[laurel]

marking verified as a duplicate

Comment 36

[Dawn Endico]

This bug was marked as a duplicate of 47786 but this bug has test cases and
analysis and that bug does not. Reopening this bug and marking 47786 as a
duplicate of this.

Comment 37

[Dawn Endico]

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

Comment 38

[(not reading, please use [e-mail] instead)]

over to mscott, as it is message pane related.

Comment 39

[laurel]

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

Comment 40

[Håkan Waara]

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

Comment 41

[Håkan Waara]

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

Comment 42

[Peter Lairo]

This is happening very often on moderately long subject ( also *with* spaces!),
where there is also an attachment. It makes the app look broken in most cases
where there is an attachment.

Suggest KW: nsCatFood, nsBeta1

Comment 43

[Scott MacGregor]

during some recent performance optimizations the subject box lost it's flex.
This stopped us from wrapping the subject line at all. I just put the flex back
on it so we should be wrapping properly again for subjects with spaces.

Comment 44

[laurel]

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

Comment 45

[laurel]

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

Comment 46

[laurel]

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

Comment 47

[Duane Clark]

The bug that I submitted, 112306, is marked as a duplicate of this bug. While it
is very similar to this bug, and is almost certainly closely related, it is
still there on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011203
Also, the bug I submitted has been around for many months. It is not due to a
recent change in Mozilla.

Comment 48

[Håkan Waara]

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

Comment 49

[Christos Cheretakis]

Also note:
if a message has a very long To: header (>30 addresses), AND that header is
expanded, the message list & message pane are covered by the headers.

Comment 50

[Scott MacGregor]

This bug is back to the normal severity is one in july (long subjects without
any spaces cause the problem). For a brief period of time long subjects with
spaces were causing the problem too (and this made it very severe) but I put the
missing flex back which restored wrapping. Not a 097 stopper. We'll start taking
a look at bugs like this once we are out of our performance freeze. 

Comment 51

[[e-mail]]

I've exhausted my XUL and CSS knowledge, and I haven't found out how to stop a
label's width from being less than the width of the longest word. Until that is
fixed the only workaround seems to be to make the subject a single line.

Comment 52

[Robert Ginda]

ChatZilla inserts <wbr> elements (used to be 0px images) in long words, in order
to allow mozilla to break them up.  In addition, bug 99457 was filed to add a
-moz[-pre]-force-wrap attribute to css, which would eliminate the need for the
<wbr> hack.

The splitLongWord function at
http://lxr.mozilla.org/mozilla/source/extensions/irc/js/lib/utils.js#503 is used
to find a nice place (a non-word character within a range of +/-5 of the desired
break position) to insert the <wbr>.

Comment 53

[[e-mail]]

Attachment: Change label to plain readonly textbox

This changes the label to a plain readonly textbox which while still only a
single line is scrollable and usefully is also copyable, which solves another
bug.

Comment 54

[Håkan Waara]

Another solution would be to use textboxes throughout the widget for all message
headers, and then add some CSS to the skins so the textboxes look like usual
labels.  That would:

1) make the headers selectable (another mostfreq bug), 

2) it would solve the wrapping problem, because too long subjects would overflow
inside the <textbox/>.

3) it would solve *another* headers bug where the maximized header widget takes
up all the space that the messagepane needs, making the email unreadable.
Because we could set a max-height of the textbox.

I really think this is what we should do, because it will fix a number of major
bugs with message headers.


Some problems with your patch, Neil:

1. Your patch touches a bunch of stuff which isn't at all related to this bug.
2. It only changes one label to be a textbox, so the widget will be inconsistent.
3. It doesn't fix all the other bugs in one fell swoop, like we could, if we go
with my above suggestion.

Comment 55

[Håkan Waara]

Neil and I are discussing a fix to this bug...

Comment 56

[[e-mail]]

Attachment: Correct patch

It does help if I attach the right patch to the right bug...

In this patch, ordinary header fields now are textboxes instead of labels.
Also, all of the text in the To/CC lists is set to wrap.

Comment 57

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch that fixes the problem for me

This patch fixes the problem for me (and for long from as well), with only
changes to the CSS.  (The changes to the XUL aren't really changes -- they're
just indentation changes, since I got tired of reading XUL that was
inconsistently indented to the point where a start-tag and the corresponding
end-tag weren't even in a bunch of places.)  This patch also has some other CSS
cleanup -- fixing a few CSS errors, fixing the problem that the search box
wouldn't allow the message tree or the message itself to get narrow when the
window was narrowed, and fixing some namespace issues in messageBody.css. 
There are some comments in my CSS cleanup that are really questions, though...

Comment 58

[Ben Bucksch (:BenB)]

dbaron,

you change messageBody.css. Is that necessary? I thought, this file were only
used for the *body* section, not the grey header area, while this bug is about
the latter. The "header" stuff you see there are for headers displayed in the
body section, e.g. from forwared msgs.

I suspect it's offtopic, but since you attached the patch here, I'll respond here:

You readd the namespaces, which previously caused the rules for the plaintext
styling to break completely. Did you test that all that stuff still works?
Please try
- All the mail.*quote* backend prefs.
- Normal (non-flowed) plaintext and format=flowed
- Signatures with links
- A smiley
Make sure that everything looks as without your change.

re your questions in the patch:
> html|*.moz-signature > html|a
> /* XXXldb What about visited links

I don't care much, because it's just the sig. Add a rule, if you want, but make
sure its color fits with the other sig colors.

> and what about links within children? */

What is that?

> html|*.moz-txt-sig > html|a,
> html|*.moz-signature > html|a
> /* XXXldb What about non-child descendants

For .moz-txt-sig, they don't exist. The html is generated from plaintext, and
there are no grandchilds of the .moz-sig-txt generated (unless you have a quote
in the sig, maybe, but then you don't want the color change anyway).

For .moz-signature (HTML signatures, composed and sent as HTML), they could
exist. It's probably good to remove the >, if that change doesn't decrease perf.
If it does, depends on how the renderer works - does it go up or down the doc
while applying/checking selectors? In the latter case, it's no prob. Anyways,
it's not important, because HTML sigs are likely to contain visual formatting
like colors, which mess up our coloring anyways.

> [background]
> /* ... this should work now.  How do I tell? */

I don't remember, maybe try to change the background color in the Nav prefs.

> margin: inherit; /* XXXldb why? */

Because <blockquote> usually adds a top and bottom margin. This is not desired.

<example type=source>
somebody wrote:
> hi there

hi!
</example>

would generate (simplified):

<example type=html-output>
<pre>
somebody wrote:
</pre><blockquote type=cite><pre>
hi there
</pre></blockquote><pre>

hi!
</pre>
</example>

With the margin, it would look like:

<example type=visual-output>
sombody wrote:

| hi there


hi!
</example>

Obviously, this is wrong.

The inherit removes the margin of the blockquote, by using the margin values of
the parent node in the doc, which usually has no margin.

> html|*.moz-text-plain[graphical-quote="false"] html|blockquote {
> border-left: inherit; /* XXXldb why? */

Simiar here. In this mode, you should see ">"s. Since this is switched via CSS
only, the usual indention and bar of <blockquote type=cite> is unwanted, or
you'll end up with

<example type=visual-output>
somebody wrote:
| > hi there
</example>

Comment 59

[Ben Bucksch (:BenB)]

dbaron,
> @namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
> @namespace html url(http://www.w3.org/1999/xhtml); 

Can't you just do something like
@namespace url(http://www.w3.org/1999/xhtml);
@namespace xul url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

IIRC, most of the stuff is HTML, so this would improve readability, because you
wouldn't have to add all those "HTML|*".

Anyways, if the change is not required to fix this bug, I suggest that you file
a new bug (and cc me) about this namespace change, because it is larger and has
some risk (as previous regressions have shown).

Comment 60

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Using the default value rather than 'inherit' would make much more sense if
that's what you want.

Comment 61

[laurel]

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

Comment 62

[walter sheets]

While this problem is much improved now, there is still the original problem
with displaying the headers of messages with attachments:  when the gray
header area is open and the MailNews window is a bit narrow then the scrollbars
for the subject and message panes are forced off the right edge of the window
which makes them invisible.

If this happened only when the window was unreasonable narrow then I'd say
live with it, but narrowing the window even moderately will make the scroll-
bars unavailable when the headers/attachments are displayed.

Comment 63

[[e-mail]]

Attachment: 62514 broke collapsed headers, sorry

Comment 64

[Michel Poleur]

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

Comment 65

[Scott MacGregor]

I haven't had a chance to look at these patches yet. I'll try to do that tby the
end of the week. 

Comment 66

[laurel]

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

Comment 67

[savardd]

Attachment: Sample Local Folder with a long 'TO:' value

This local folder contain an HTML e-mail 'Les nouvelles de DreamCity' which
cause the 'preview' and the 'message list' panel to resize themselves.	The
message list panel loses its scroll bar.

Also, as a side effect, when viewing this message the file, edit and all other
menus becames very slow.  What I want to say is that moving the mouse in these
menus (when opened) is very slow (the blue 'reverse' line isn't able to follow
the mouse, it is very late).  If had scroll bar at right and are viewing the
message 'Les nouvelles de DreamCity', while browsing the menus, the scroll bar
will appear blinking and very weird.  I don't know if this should be a new bug
or not.

Comment 68

[laurel]

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

Comment 69

[laurel]

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

Comment 70

[Ninoschka Baca]

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

Comment 71

[laurel]

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

Comment 72

[Peter Lairo]

Add "long CC-lists" to the cause of this bug in the subject line:

OLD: 
emails with long subjects make it impossible to see the attachment tree and make
thread pane go wild, if message pane is visible and you are not in "collapsed"
header view.

NEW:
e-mails with long subjects (or CC-lists) make it impossible to see the
attachment tree and make thread pane go wild, if message pane is visible and you
are not in "collapsed" header view.

Comment 73

[scottputterman]

reassigning to ssu.

Comment 74

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: updated version of patch in attachment 62713, with only parts related to this bug

This only includes the parts related to this bug.  I spun off the
messageBody.css mess into bug 130728, which I'll probably Future, and I'll just
let the other CSS error fixes rot in my tree since nobody else cares much about
CSS errors...

Comment 75

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 73977 [details] [diff] [review]
updated version of patch in attachment 62713 [details] [diff] [review], with only parts related to this bug

Note that the change to msgHdrViewOverlay.xul is **only** an indentation change
-- the file was inconsistently indented, and it confused my while trying to fix
this bug.  The CSS changes are all that's necessary to fix this bug.  The
changes to the rules with selector #searchBox fixes the same problem with the
search box as the other changes fix for the header pane.  Fixing the header
pane doesn't do all that much good for small window sizes without the search
box fix as well.

Comment 76

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 73977 [details] [diff] [review]
updated version of patch in attachment 62713 [details] [diff] [review], with only parts related to this bug

Actually, never mind.  This patch doesn't seem to work for me anymore, at least
for messages with attachments.

Comment 77

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 73977 [details] [diff] [review]
updated version of patch in attachment 62713 [details] [diff] [review], with only parts related to this bug

Actually, never mind.  This patch doesn't seem to work for me anymore, at least
for messages with attachments.

Comment 78

[Michael Buckland]

Discussed in Mail News bug mtg with Engineering, QA, Mktng, PjM.  Decided to
minus this bug. 

Comment 79

[Peter Lairo]

I suggest mozilla.org reconsider *plussing* this bug because very many AOL users
frequently send attachments (jokes, viruses, etc) to all their relatives or
friends. AOL users seem to love to spam the people in their addressbook.
Nevertheless, this bug will be highly visible to a large number of people.
 It is a kind of *in-your-face-brokenness*.

Comment 80

[Russell Odom]

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

Comment 81

[Asa Dotzler [:asa]]

This is one of the more visible mailnews UI problems. I hope that we can find
resources to make this happen. adding mozilla1.0+ keyword.

Comment 82

[Dawn Endico]

This is #27 in our list of most duplicated bugs. It affects people with lower
resolution screens the most. People with 640x480 screens will see this a lot
and people at netscape who maximize the mail window on their ultra high
res 21" monitors will probably rarely ever see it. Workaround for this bug:
Buy a g4 with a new 23" cinema displays. =)

Comment 83

[Peter Trudelle]

While I also think this should be fixed, we should note that the product is
designed for a minimum display size of 800X600, users with only 640X480 are
bound to be dissatisfied.

Comment 84

[Duane Clark]

This is NOT just a problem when running 640x480. I run 1600x1200, and run into
this bug almost every day. I imagine that most people do not run Mozilla
maximized to the size of the screen.

Comment 85

[Scott MacGregor]

You mean you get a message which has a huge number of characters in the subject
without a space very day? We properly wrap long subjects if there is a space in
the subject. The problem is when there isn't a space. 

Comment 86

[Duane Clark]

This bug has accumulated a number of related bugs, for example one I submitted:

http://bugzilla.mozilla.org/show_bug.cgi?id=91662#c47

That is why there are so many duplicate bugs attached to this one. Specifically,
the place where it is triggered for me is when an email or posting has an
attachment, along with some long names in the To: or CC: header. And yes I do
get those almost daily.

Comment 87

[Scott Davis]

I also get mail with long To or Cc addresses and attachments most days.

My screen is 1280x1024, but I don't have the mailnews window maximised - I 
usually have it over roughly the left half of the screen with a browser window 
next to it in the right half.

The biggest problem for me with this bug is that I sometimes miss the fact that 
the whole message is not visible on the screen, as the scrollbar is invisible.

Comment 88

[Dawn Endico]

This isn't just about ridiculously long subjects as in the test case i wrote.

Changing summary to hopefully make it more clear. This also happens
with relatively normal looking mail. A lot of from addresses come in
the form: "[e-mail]"<[e-mail]>  (Note that there is no space
between the quote and the brace). If such a person sends a mail with
an attachment, then their email address doesn't have to be very long
before it doesn't fit and starts pushing stuff off the right edge of
the window. It doesn't have to push very far before the scroll bars
fall off the right edge of the window and make the window unusable.
See comment 28.

It happens to me a lot less often now that i rarely use my 800x600 laptop.


Old Summary:
Emails with long subjects make it impossible to see the attachment tree and make
thread pane go wild, if message pane is visible and you are not in "collapsed"
header view.

New Summary:
Long strings in mail header cause scroll bars and attachment window to
disappear, making message unviewable.

Comment 89

[yatsu]

LOL. Bugzilla handled that quite gracefully.

Dawn, you might want to change the summary again :)

Just to add something relevant to this bug.

Every single user I've encoutered during my time in tech support have their
email client maximized. 

The best fix for this is a simple one: place the header in the message pane.

Comment 90

[Mike Young]

fixing summary... Dawn wins the Longest Summary Award!

Comment 91

[Koike Kazuhiko]

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

Comment 92

[John Muir]

Attachment: Image of my mozilla mail window with the formatting broken.

This shows how simply including the attachment pane with LONG e-mail addresses
(which include spaces) and a short subject, cause a similar issue to that which
is described by this problem.

Comment 93

[John Muir]

Attachment: A message in the same list which doesn't have an attachment.

This image is of the same mail window as attachment #76566 [details], but the message
being displayed doesn't have an attachment. Note missing scroll bar for the
message list  in attachment #76566 [details]. These are with Mozilla 0.9.9.

Comment 94

[Nick Lewycky]

Didn't know this bug existed--been seeing this for a long time. There's another
artifact I've found, can anyone confirm it? If the display is busted like
attachment 76566 [details] and you mouseover a link in the content pane, it causes the
chrome part (the list of messages) to "vibrate." That is, it resizes itself so
that the rightmost edge of the content (which was beyond the edge of the window)
moves at the right edge of the window even though that overlaps the list of
accounts to its left... only to move back an instant later. This happens again
when you mouseoff a link. Running the mouse up and down a link in the message
body should demonstrate this easily.

Comment 95

[Scott Davis]

Yes. I've seen vibrating chrome in MailNews, but hadn't bothered to work out
when it happens. As it mostly seems to show up at the same time as this this
bug, I presumed it will go away when this is fixed properly.

Comment 96

[R.K.Aa.]

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

Comment 97

[R.K.Aa.]

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

Comment 98

[laurel]

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

Comment 99

[Toylet]

I noticed that the bug will only appear when you use windowing layout that 
features the biggest message panel (ie, 2-upper-1-lower). clearing old mozilla 
settings would NOT help.

I think the display issue could be avoided by shortening those long header 
fields (from:, to:, subject: ...). That is, by replacing
"To: [e-mail]"
with soemthing like
"To: sadfkljasdk..."

of course, the real content was not changed, only the display.

BTW, #139461 has test cases. also got a image of the error.

Comment 100

[Toylet]

I just noticed that there was no scroll-bar when there were more attachments 
that could be displayed in the attachment box.

Comment 101

[Peter Lairo]

There *is* a scrollbar. You just can't see it *MOST* of the time because this
bug causes the scrollbar to move off-screen as soon as *any* element in the
header (subject, From, To, or attachment filename) is wider than the header
itself. :(

Comment 102

[Peter Lairo]

Attachment: Better screenshot of this bug showing also desktop as reference

Comment 103

[R.K.Aa.]

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

Comment 104

[Raphael Clifford]

Are the "vibrating panel separator" and "losing scrollbar and attachment
windows" bugs really the same?  If so, could we put the "vibrating panel
separator" into the summary as well. If not, we need another bug. For the
record, I get the  "vibrating panel separator" problem but not the missing
scrollbar etc. problem.  It isn't obviously related to long strings in the
headers either, at least for me.  Build is Mozilla/5.0 (X11; U; SunOS sun4u;
en-US; rv:0.9.9+) Gecko/20020424 (sparc solaris).
Raphael

Comment 105

[Scott MacGregor]

the vibrating panel button is a different bug. It's a recent regression that
causes some windows to go into an infinite reflow loop where a scroll bar is
added then removed then added again, etc. We're trying to find a fix. It's a top
moz 1.0 bug: 
Bug #121583.

Comment 106

[Peter Lairo]

> It isn't obviously related to long strings in the headers either...

True, it has to be *one* long string (as in a lond e-mail address), or a medium
string and an attachment (as soon as the attachment window AND/OR the string are
wider than the mail window (which is pretty often, if you ask me). :(

Comment 107

[R.K.Aa.]

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

Comment 108

[R.K.Aa.]

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

Comment 109

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 110

[Ian Batterbee]

I believe bug 142988 is a dupe of this ... I haven't paid much attention to this
bug and it's too much to read right now (sorry) - can someone that knows exactly
what this bug is on about review 142988 and set the dupe field appropriately if
it turns out to be the same thing. Ta

Comment 111

[Dawn Endico]

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

Comment 112

[R.K.Aa.]

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

Comment 113

[R.K.Aa.]

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

Comment 114

[Alan Eliasen]

I'd recommend that the priority gets increased; it almost *always* breaks news
articles with attachments because news articles almost inevitably have a very
long line indicating the route that the article took to my news server:

Path:
mindspring!newsfeed0.news.atl.earthlink.net!news.atl.earthlink.net!washdc3-snh1.gtei.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newscon02.news.prodigy.com!prodigy.com!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn4feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail

(I also had to use a different news client just to paste this in, because
Mozilla won't let you cut-n-paste mail headers, another critical problem.)

This simply makes Mozilla unusable for reading news with attachments.

Comment 115

[Jerry Baker]

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

Comment 116

[Jerry Baker]

See http://bugzilla.mozilla.org/showattachment.cgi?attach_id=75670 for example 
of this happening with a news message that has a long Path: header. Almost all 
news messages have a long path header. Notce that the scrollbars are gone from 
BOTH the message list and the message itself.

Comment 117

[Jerry Baker]

Adjusting summary to reflect news phenomena.

Comment 118

[Felix Miata]

Bug 132909 duped to this was severity "major". This should be the same or worse.
See bug 132909 screenshots. Mozilla currently as a newsreader is clearly
inferior to Netscape 4. This ought to be 4xp as well.

Comment 119

[Håkan Waara]

As far as I can see, this bug depends on bug 99457. Marking dependency.

Comment 120

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Not really, since we can clip the long lines instead of expanding the window.

Comment 121

[Toylet]

guys, I just noticed that I could drag the vertical spliter bar (the one that 
sseparate the upper 2 listbox) to the left till it CROSSED the scrollbar of the 
folder list listbox momentarily. 

You need to use 3-window mode, and maybe large fonts in Window$' scheme, 
800x600 resolution. 

This behaviour may be relatd to this bug, but I am not sure. I will attach an 
image...

Comment 122

[Toylet]

guys, I just noticed that I could drag the vertical spliter bar (the one that 
sseparate the upper 2 listbox) to the left till it CROSSED the scrollbar of the 
folder list listbox momentarily. 

You need to use 3-window mode, and maybe large fonts in Window$' scheme, 
800x600 resolution. 

This behaviour may be relatd to this bug, but I am not sure. I will attach an 
image...

Comment 123

[Toylet]

Attachment: the vertical splitter crossing the scrollbar of the mail folder listbox

Comment 124

[casioqv]

Attachment: a screenshot of this bug under windows 98

when this e-mail is viewed the message list suddenly becomes only 1.5 emails
tall but goes back to the regular height when a new e-mail is selected. You can
see that this bug manifests itself a little differenly on windows but is still
very very annoying and should be fixed before the release of 1.0

Comment 125

[Jerry Baker]

I think that comment 124 is another bug. This bug is about scrollbars 
disappearing. Yours appear to be intact.

Comment 126

[Adam Macznik]

I think comment 124 is the correct behaviour when headers are too high. With
"All" headers view it always moves the horizontal split to fit the header info
on the screen.

Comment 127

[Peter Lairo]

There is a pathch in bug 106927 comment #97 that may also fix this bug.

What it does:
"It changes the tab container so that when the tabs overflow, they are cropped on
the right-hand side, instead of growing the container and pushing the rest of
the UI off screen."

Could this be used to fix this bug? Even if it may not be an ideal fix, please
consider if it will at least be better that the current situation. If so, the
patch is already there waiting...

Comment 128

[Aaron Kaluszka]

Note in that bug that I said that the *concept* and not the patch itself will
fix this bug.  I am currently seeing if I can apply the same concept to this
problem, but somebody with more (as in any) XUL experience should look at this.

Comment 129

[Aaron Kaluszka]

... and I meant to say in my last comment, *could* fix this bug, not *will* fix
this bug.  Upon investigation, it is not the container, but the text itself that
is causing the problem.  Therefore, the only way to fix this is to change the
text fields to a different type or change the inherent properties of the text
field.  Probably the latter considering that the fields were changed to this
special header type from generic text fields.  That is unless there's some
special container type that I don't know about.  This bug and bug 61497 could
probably be fixed relatively easily at the same time.  While experimenting, I
did come up with a quick fix.  Splitter bars can be added to components like the
headers, which enables the offending strings to be collapsed.  That's not a very
good solution, though.

Comment 130

[[e-mail]]

Attachment: Patch to address(!) email addresses only

This patch allows embedded spaces in email addresses to wrap.

Comment 131

[laurel]

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

Comment 132

[[e-mail]]

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

Comment 133

[[e-mail]]

Attachment: Revised email address patch

Oops, previous patch broke the context menu.

Comment 134

[Bill Mason]

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

Comment 135

[R.K.Aa.]

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

Comment 136

[R.K.Aa.]

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

Comment 137

[Sean Su]

Comment on attachment 89053 [details] [diff] [review]
Revised email address patch

I haven't applied the patch, but one obvious thing I see is that the
UpdateMessageHeaders() call should not be moved into buildLongView().  It needs
to be left in toggleAddressView().

The comment has a typo.  It should indicate that UpdateMessageHeaders() should
not be called from "buildLongView()" (as opposed to "buildView()")

I'm still reviewing the patch.

Comment 138

[Alfonso Martinez]

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

Comment 139

[Asa Dotzler [:asa]]

sean, neil, what's the status of this bug/patch?

Comment 140

[R.K.Aa.]

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

Comment 141

[David G King]

As v1.1 has branched, and there hasn't been much recent activity (last was
almost a month ago), should this still be a blocker for v1.1's release? I say
that as this bug isn't, IMHO, high profile in that it only happens under rare
circumstances.

Comment 142

[steve bowden]

Don't understand about it being rare circumstances. I get emails with long cc
lists every day! This makes the scroll bars disappear. Also, if after displaying
full header the header is made brief (by clicking on the pointer) the header
info stays in the content pane!

This is NOT an obscure problem!

Comment 143

[david]

On the contrary I use Mozilla mail in the office connecting to an Exchange IMAP server and every time someone sends an email to a preconfigured address list, the email address formed is so long that it causes the problem. I see this bug several times every day, and would certainly appreciate a fix for it. 

I've found ways to work around it so it's not a major issue but it is a blot against an otherwise excellent email tool.

Thanks
David.

Comment 144

[Mitch]

Just by looking at the cc list/votes one can see this is NOT an obscure
or infrequent problem. It is being tolerated on a daily basis on the
faint hope that it will get fixed eventually. It is a real nuicance and
makes the mail reader unuseable when long subject/gecos fields are
recieved since you either lose the scroll bars, lose the attachments
pane, or get continuous jittering of the message pane.

Comment 145

[Ian Nartowicz]

I agree, its not obscure.  Its a day-to-day fact of life using the Mozilla mail
front end for many users.  Most of the problems it causes are minor but it is
very visible.

I'm not really in a position to say if it should be a 1.1 blocker, but I would
have thought the whole point of 1.1 was to fix many of the
visible/annoying/serious bugs that couldn't safely be handled in 1.0.

Comment 146

[walter sheets]

As an amateur programmer for 25 years I've created a lot of bugs myself, and
fixed a lot also.  My observation has been that when a bug is this hard to
fix it's because the program design was wrong from the beginning.

The first time I used mozilla I remarked that putting the headers in a
separate panel seemed an odd and unnecessary thing to do, and I still
think so.

Other mail readers stuff the headers in the same panel with the message
and do just fine.  I would strongly urge you to do the same and move on
to something more important!

Comment 147

[Daniel Amor]

I believe Walter is right, if we cannot fix the bug easily by adding fixes,
probably the whole concept needs to be rethaught. Therefore we should review the
reasons why it has been implemented in the way it is now and see if other
concepts would reduce the usability of the solution or not. Based on this
evaluation we would need to agree on an alternative concept that provides at
least the same functionality without the same defects.

Comment 148

[Betsy]

I work with graphics and it is impossible to receive graphic attachments, fonts,
etc with this bug. I have to go to another mail reader to use my mail. I *hate*
using Outlook Express.

This is *not* trivial.

Comment 149

[Jerry Baker]

Walter Sheets: See bug 9942 to see about Mozilla putting headers in the message
window.

Comment 150

[walter sheets]

I looked at the previous discussion in Bug 9942 and the only thing I can see
that is compelling is the argument that users are expecting scrollable,
selectable headers.

I want to go on record as NOT expecting scrollable, selectable headers!
I much prefer to have the headers inline if I want to see them, and
invisible if I don't want to see them.

The argument for converting inherently non-HTML text (i.e. headers) into
HTML is a specious one, IMHO.  Do you want to click on an email address to
send a response?  So click on REPLY or some variation thereof.  Do you want
to fetch a referenced message I.D.?  So click on FETCH PARENT ARTICLE or
some variation thereof.  Do you want to forward headers to an abuse department?
(Hah!)  Then click on some variation of FORWARD HEADERS.

I think the proper design goal is to identify what tasks the user might have
and then design a button or menu item to accomodate that task, rather than to
force an inherently un-natural conversion between hostile formats (HTML being
the hostile format, of course ;-)

Comment 151

[Ian Nartowicz]

The things I picked up on from the other thread were: the twisty; the attachment
pane; and skinnability.  None of these seem absolutely vital.  Sure, it's nice
to have the twisty instead of the NS4 view menu options, and its nice to have
that little pane with the attachments, but not at the expense of it not working.
 Skinnability seems like a non-issue, if the headers are displayed as text they
will look like text and there will be no need to mess with chrome.

The current implementation has clickable addresses but not the ability to select
text, in particular from the subject line - that's a nuisance but not a serious
problem.  But I think there absolutely has to be a way of seeing the entire
header when it is very large, and it seems like making it scrollable is the
sensible.  I guess you could do that by making the pane scrollable or by putting
the header inline.  Putting the header as inline text might be a little less
slick but at least it would work, until and unless someone can program that pane
to work correctly.

Comment 152

[Trevor Boicey]

Having selectable elements in headers is very important in many ways.

Obvious point, how many times do you get an email where the subject contains a
URL? In my case, very often, both from script generated email and friends who
send things like "Have you seen http://www.web.site.com?"

As well, often the subject contains an email address that you want to use. If
you can't even select the text, not only can you not click on it to view the URL
or mailto the email address, you can't copy and paste it. You have to retype it,
which gets silly with a 80 character alphanumeric GET query URL.

I use a lot of scripts that send myself web pages and such, with the URL in
the subject and the body as the content. So not only do I often want to use the
subject headers to click on to go to a page, which I can't, I can't select the
URL and paste it into the browser, and because the scroll bar is gone, I can't
view the page in the message window either.

So I end up basically screwed, or using some workaround like grepping the URL
from the Inbox file in .mozilla, or clicking on a link on the page that I know
links back to the page I really wanted.

To summarize again, depending on user practice, this bug can be fairly crippling.

So... I would certainly put functionality ahead of sexiness, what good is having
my message header skinned with brushed titanium while I'm grepping my Inbox to
pull out a URL?

Comment 153

[Christos Cheretakis]

Let me say, however, that the attachments pane is pretty useful and shouldn't be
removed without second thought!

Comment 154

[Felix Miata]

Netscape 3 & 4 mail did and do work fine. Mozilla trying to be like M$ O/OE
stinks. Mozilla  for mail and news is currently little better than useless (not
just because of this bug). Let's make it work now and add flash later if flash
is really needed and/or wanted. Scrap chrome message headers.

Comment 155

[walter sheets]

I use mozilla mail every day, so I don't agree that it's next to useless,
but I rarely look at headers, and the only URL's I ever see in the
subject line are obvious spam :-(   (Different strokes...)

Is there a technical reason the header pane can't have a separate horizontal
scrollbar to take care of the long-header problem?  If it's a shortcoming
of the API/toolkit then the design of the program must be changed to fit the
available tools.  Otherwise, it seems to me that the horizontal scrollbar is
the obvious solution, no?

Comment 156

[Felix Miata]

You must be easy to please. I actually use 4xp routinely for mailnews.Here's a
partial list of why I wrote what I wrote:

Bug 4302 - over five years old; works fine in 4xp
Bug 21344 - 4xp superior
Bug 54911- another 4xp superiority
Bug 109935 - pure slop
Bug 118899 -  4xp ho hum
Bug 129052 - hard to imagine something so simply useful was discarded
Bug 134333 - more XUL slop
Bug 134635 - &
Bug 135964 - &
Bug 148267 - &

The browser is first class, Mailnews is last class.

Comment 157

[Ian Batterbee]

Okay, I'll ask.. I surely can't be the only person reading that last comment
that's wondering what on earth 4XP is.

What's 4xp ?

(and feel free to flame me.. as that seems to be the norm when I ask something
about a bug in here. All flames will be tidily placed in /dev/null)

Comment 158

[Scott Davis]

I'm another one who hits this bug every day. On the rare occasions I need to
copy something out of the header fields, I use view page source (ctrl-u) to see
the headers as text.

Comment 159

[Rob North]

I was quite surprised when a mail dropped into my mail box suggesting
this is not a siginficant problem.
It is. 
The smaller your secreen, the more of a problem it is.
If you wish to use 800x600, or have to, you'll be in trouble.
Similarly it will make use of the mozilla mail reader v. difficult for the
visually imparied.
Even I, using an 1600x1200 screen often find e-mail messages that screw with the
scrollbars.
It makes some particularly mangled spam especially annoying.

Comment 160

[Kyle Yuan]

I suggest a possible fix for this bug:
1) In the message preview window (messenger.xul), make the attachmentBox's 
flex=1 and make the text of Subject, From, To, etc. "croppable";
2) In the message window (messageWindow.xul), put attachmentBox below the To, 
CC items, rather than right of the header pane.

Comment 161

[walter sheets]

I just looked at Sun's StarOffice 5.2 which appears to have done already
what mozilla is aiming at.  Perhaps Kyle was also referring to their work.

The header panel is in the center with a vertical separator between the
headers and the list of attachments. The vertical separator can be moved
with the mouse as far as desired in either direction, even so far as to
obliterate the headers or the list of attachments if you want

When the main window is narrowed, the width of the attachments pane stays
constant and the header window shrinks as much as needed while the headers
wrap automatically rather than truncate--all the way down to zero if you
want.  This inherently solves the long header problem.  Whether you like
their approach is another question, but it works.  There are no horizontal
sliders in either pane, though I can't see why you couldn't add one to
the header pane if you don't like the wrapping headers.

The location of the combined header/attachment pane also re-locates itself
automatically up along side the article list, so as to accomodate large
images in the body pane as needed.

Comment 162

[Toylet]

the simplest and possibly quickest solution is to display long lines with this 
format:

"this is a very long .... long time"

use "..." to represent the mess in the middle. 

Comment 163

[R.K.Aa.]

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

Comment 164

[R.K.Aa.]

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

Comment 165

[[e-mail]]

Sean Su wrote:

> (From update of attachment 89053 [details] [diff] [review])
> I haven't applied the patch, but one obvious thing I see is that the
> UpdateMessageHeaders() call should not be moved into buildLongView().
> It needs to be left in toggleAddressView().

Sorry, my fault for not checking the diff, you can ignore that bit.

Comment 166

[(not reading, please use [e-mail] instead)]

ok, I think I have the start of the fix for this bug.

at least, I have a hack.

I'm trying to get crop to work, through xbl.  I'm not having luck yet, but I 
know it can be done.

here's a hack that changes the code to not use the xbl widget 
mail-toggle-headerfield.  instead, I've exploded it out into the xul.  when I 
do that, crop works.

but when it's an xbl widget, I can't (yet) get crop to work.

Comment 167

[(not reading, please use [e-mail] instead)]

Attachment: hack.

Comment 168

[(not reading, please use [e-mail] instead)]

taking back from ssu.

what I'm trying to do is get it so the headerValue label in the mail-toggle-
headerfield widget (see mailWidgets.xml) will crop.

this isn't working:

<xul:label class="headerValue" anonid="headerValue" crop="right" 
flex="1">*</xul:label>

Comment 169

[(not reading, please use [e-mail] instead)]

Attachment: a non-hack. I need to talk to mscott about the headerValue, but this makes it works for me.

Comment 170

[(not reading, please use [e-mail] instead)]

accepting.  here comes a screen shot...

Comment 171

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of an email with a long subject, and an attachment.

Comment 172

[(not reading, please use [e-mail] instead)]

re-reading the bug, it sounds like other headers (besides subject) can cause 
this to happen.

once I get a review for the subject fix, I can look into the other headers.

Comment 173

[(not reading, please use [e-mail] instead)]

For the record, this works:

<xul:label class="headerValue" crop="right" anonid="headerValue" value="*" 
flex="1"/>

But this doesnt:

     <xul:label class="headerValue" crop="right" anonid="headerValue" 
flex="1"/>*</label>

I think that makes sense, because in the second case, "*" (or the subject) is 
just a child node of the label, instead of the value.

Comment 174

[jay garcia]

Seth: It's the PATH header that seems to be the longest and most problematic as
far as I can tell from the activity in the groups.

Comment 175

[(not reading, please use [e-mail] instead)]

Attachment: patch for all headers

patch that fixes all headers.  now that we aren't doing the .firstChild thing,
we probably don't need to default the value to "*".

I'll try that, and supply a new patch.

Comment 176

[(not reading, please use [e-mail] instead)]

Attachment: remove value="*", not needed

this patch fixes the long "Path" header problem that jay garcia mentioned.

Comment 177

[Kyle Yuan]

I would like to wrap the text rather than crop it, because then we will lose the
way to see the whole content of mail header in the preview pane even in the
messageWindow.xul.

Comment 178

[Felix Miata]

Please wrap instead of crop.

Comment 179

[Peter Lairo]

Please wrap instead of crop. The *entire* subject line must be readable.

Comment 180

[(not reading, please use [e-mail] instead)]

how would you wrap something like:

"nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn"?

Insanely long subjects are available in:

1)  the 3 pane window title, when the message is selected
2)  the stand alone msg window
3)  view message source

On problem with wrapping (especially in the preview pane) is it can make the 
header area too big (after this patch, too tall), and force the body of the 
message off screen, requiring the user to scroll.

Comment 181

[(not reading, please use [e-mail] instead)]

note, the you'll be able to see more of the subject (and other long headers) in 
the stand alone msg window than in the preview pane, since the header area will 
be bigger.

also, this patch makes us behave like Outlook Express.

Comment 182

[Peter Lairo]

No. The ENTIRE subject must be readable in the preview pane, because:

1) The window title is *not* long enough to show long subjects (and we shouldn't
be relying on this anyhow!).

2) I _never_ use the stand alone message window (and we shouldn't be relying on
this anyhow!).

3) We should not expect users to go to (let alone know about) "view message
source" (and we should _definately_ not be relying on this anyhow!).

Even the most extremely long subject line (~255 caracters) will almost certainly
never make the header so tall as to make the body unreadable. On the other hand,
CUTTING OFF the subject will most certainly make the subject of the message
UNREADABLE.

I frequently whitness e-mails (usually from Lotus Bloates users) where the
(long) subject line contains the actual message (and the body is left empty).
For this case alone, we should make absolutely sure that the entire subject line
is readable in the preview pane's header.

Now to your (unlikely) example of a long subject without spaces:

At a minimum, we should be checking if there are spaces (say: at least every 20
letters) in the subject line and create the linewrap(s) there. Only _IF_ there
are _no_ (or insufficient) spaces would I agree to cutting off the subject line.

But, even if there are NO SPACES, there must be some way to wrap. Perhaps
_forcing_ a wrap at the right border position, regardless if its in the middle
of a word or not:

ThisIsAVeryLongSentenceWithoutAnySpacesToShowHowWrappingShouldBeForcedRegardle
ssOfWhereTheWordEnds

PS. LookOut Express sucks Donkey-Dung, and shouldn't be our excuse to take the
easy route.

Comment 183

[[e-mail]]

Seth, if you're going to crop the headers you might as well switch them for
textboxes (as per attachment 70284 [details] [diff] [review]) thereby simultaneously fixing bug 61497.

Comment 184

[Ben Bucksch (:BenB)]

> how would you wrap something like: [...]

Force a break after n chars.

> 1)  the 3 pane window title, when the message is selected

This is a bug.

> 3)  view message source

This is for experts only.


Showing at least a reasonably long part of the subject (e.g. 300 chars) is
important. E.g. some clueless users write the first line of the msg in the
Subject. In other cases, important information like a tracking ID is only in the
later part of the subject (a bug of the sending software, it should also be in
the body, but happens nevertheless, IIRC).

> On problem with wrapping (especially in the preview pane) is it can make the 
> header area too big (after this patch, too tall), and force the body of the 
> message off screen, requiring the user to scroll.

IMO, the subject is more important than the body.


Is there a possibility to make a whole frameset scroll? (If not, would it be
easy to code?) In that case, the whole msg pane could be the frameset, with the
header pane as the upper frame and the body document as the lower frame. They
would scoll together, giving an effect similar to 4.x, but with the advantages
of XUL in the header, including different trustness of header/body.

Comment 185

[(not reading, please use [e-mail] instead)]

note to neil:  

making it so we can select and copy header text is next.  But I want to talk to 
some xul people (especially hewitt), who had some ideas on how to do this 
without using a textarea.

note to others:

1)  consider the "badness" of the original bug, and that this patch fixes it.
2)  the preview pane is small.  with such limited space, anything we do will 
have issues.  You can't fit 10 pounds of headers into a 5 pound bag.

note to peter:

"LookOut Express sucks Donkey-Dung, and shouldn't be our excuse to take the
easy route."

Continue with these unprofessional and useless comments and I'll ask 
[e-mail] to remove your bugzilla access.

Comment 186

[Peter Lairo]

Please note that this bug is usualy caused by long e-mail addresses (because
they are contiguous), and not subject lines (because they are rarely
contiguous). IMO, cutting off subject lines will do little to fix this bug (and
a lot toward making mail/news worse).

Seth: I apologize for the "unprofessional" comment. I sometimes get frustrated
when things seem obvious to me. I should have said:
"We shouldn't follow OutLooks example in cases when it is setting a poor example."

Comment 187

[Peter Lairo]

Attachment: Proof that long subject lines are NOT causing this bug

Please notice that the vertical scrollbar on the message pane is still visible
(and not moved off-screen).

If any "cropping" is to be done, then please only of the e-mail addresses.

Comment 188

[Felix Miata]

Simply saying that is how OE does it without asserting that OE does it "right"
is sort of like saying OE is a usability leader <choke> that Mozilla should
follow instead of Mozilla taking the role of usability leader.

Comment 189

[Kyle Yuan]

Attachment: proof attachment 96637 crop the subject in the stand alone msg window too

Seth: 

I applied your patch, but unfortunately, it crops the the subject in the stand
alone msg window too. So all of your way to show the whole subject line in
comment 180 is not reasonable.

Comment 190

[[e-mail]]

Comment on attachment 96637 [details] [diff] [review]
remove value="*", not needed

> .setAttribute('value', val);
This should be
.value = val;

Comment 191

[[e-mail]]

Perhaps you could use twisties to switch between cropped and wrapped view?

Comment 192

[Adam Macznik]

For the time being, I suggest to wrap lines on chars like ".@<" for addresses
and "!" for paths. This will make this bug less visible ;-)

Comment 193

[[e-mail]]

Comment on attachment 96637 [details] [diff] [review]
remove value="*", not needed

Actually the headerValue should inherit its value attribute so that the setter
can just set an attribute.
<xul:label class="headerValue" flex="1" crop="right" xbl:inherits="value"/>
<property name="headerValue" onset="this.setAttribute( 'value', val ); return
val;" onget="return this.getAttribute( 'value' );"/>

Comment 194

[Jan Varga [:janv]]

My personal opinion:
I like Seth's patch, but there should be some simple way for displaying whole
subject line or other headers.
What about using tooltips ?

Comment 195

[[e-mail]]

Jan: don't tooltips have a size limit as well?
Seth: please be sure to make header copy accessible.

Comment 196

[(not reading, please use [e-mail] instead)]

neil's textbox approach is exactly what we want.

my apologies to neil (again).

some of his earlier patches had the desire fix, but I let them bit rot.

with neils approach, we get:

1) the fix for the badness
2) scrolling subject line (you can scroll and see it all)
3) you can copy and paste headers now (except for email headers)

addressing neil's comments:

1)

> .setAttribute('value', val);

This should be
.value = val;

fixed that, thanks.

2)

Actually the headerValue should inherit its value attribute so that the setter
can just set an attribute.
<xul:label class="headerValue" flex="1" crop="right" xbl:inherits="value"/>
<property name="headerValue" onset="this.setAttribute( 'value', val ); return
val;" onget="return this.getAttribute( 'value' );"/>

we don't need the getter, so I've left it as is.

Comment 197

[(not reading, please use [e-mail] instead)]

Attachment: based on neil's patches.

patch for review.

neil, with this patch (based on your patches) two of the most painful mailnews
bugs are fixed.

you rule!

Comment 198

[Kyle Yuan]

Comment on attachment 97132 [details] [diff] [review]
based on neil's patches.

this patch works fine, but IMO, you should do the same job for the From/To/CC
fields too.

Comment 199

[Peter Lairo]

> 2) scrolling subject line (you can scroll and see it all)

Please make the subject _wrap_ to the next line. It is important to be able to
see and read the entire subject without parts of it always being concealed.

Could you post a screenshot of this "scrolling" behavior?

Comment 200

[[e-mail]]

Attachment: Changed collapsed header value setter

Seth, I think you also need to twiddle some JS in msgHdrViewOverlay.js

Comment 201

[(not reading, please use [e-mail] instead)]

got distracted by stand alone mail and some performance work.

I'll finish this up today.

Comment 202

[(not reading, please use [e-mail] instead)]

Attachment: patch, also works with keywords [checked in: Comment #206]

Comment 203

[David :Bienvenu]

Comment on attachment 97874 [details] [diff] [review]
patch, also works with keywords [checked in: Comment #206]

sr=bienvenu

Comment 204

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 97874 [details] [diff] [review]
patch, also works with keywords [checked in: Comment #206]

r=[e-mail]

Comment 205

[Asa Dotzler [:asa]]

Comment on attachment 97874 [details] [diff] [review]
patch, also works with keywords [checked in: Comment #206]

a=asa (on behalf of drivers) for checkin to 1.2a

Comment 206

[(not reading, please use [e-mail] instead)]

fixed.

I'm going to spin up a new bug about subject wrapping.

Comment 207

[(not reading, please use [e-mail] instead)]

new bug about subject wrapping RFE:

http://bugzilla.mozilla.org/show_bug.cgi?id=166892

Comment 208

[Nathan Bidwell]

Attachment: Screen Shot missing scrollbars

I don't believe this bug is completely fixed.  I have an email (attached)
which, with my current small screen resolution will cause the To: header to
push the scrollbars out of the current window.	This screenshot is of a current
Linux CVS pull where the patch *has* been applied.  (I do get a scrolling
subject with other mails.)  Unfortunately I don't have permissions to reopen
this bug.

Comment 209

[[e-mail]]

Seth, attachment 89053 [details] [diff] [review] is designed to alleviate that bug by allowing email
address to wrap internally (although ssu pointed out a mistake in that patch).

Comment 210

[Ian Neal]

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

Comment 211

[Ian Neal]

This landing may have caused the regression seen in bug 167468

Comment 212

[Ian Neal]

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

Comment 213

[Frank Loeffler]

Hi,

I just tried Mozilla 1.2a, but this bug seems not to be completly fixed, because
I got an email with attachment and the long TO-field is pushing the scrollbars
out of the window.

Please reopen this bug report.

Frank Loeffler

Comment 214

[Mitch]

I am reopening since this is not fixed. The attachment window still
disappears if you have a messages with a long gecos field.

Happens with todays build on Solaris 5.x with cvs 20020912

Comment 215

[Scott Davis]

Solaris 8, Nightly build 2002092322
This bug still pushes the scrollbars out of view with long email addresses, but
the partial fix seems to make things worse in other ways too.

It attempts to make more space by pushing the divider between the folder list
(left panel) and the header/body panels over to the left, truncating all the
folder names to be unreadable (just an icon and ...). In the process of doing
this, there is a lot of left-right shaking of the display panels as it tries to
determine how far this can be pushed.

Comment 216

[hirata masakazu]

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

Comment 217

[Christos Cheretakis]

There's another case to note. I'm pasting below two subject lines from spam mail
I've received, that contain lots of spaces.

Subject: babes babes and more babes                                            
                             7247iOrL7-135tFMl5959iswz0-114pj-30
Subject: This is REAL!                                                         
        5375pohY6-992TSGt8250EBNG0-515-28

I think their point is to be very long as to hide the last part from the user
--either my id in the spammer's mailing list, or the campaing's id the message
belongs.

Mozilla does not wrap the subject line. All spaces are displayed and the last
token is pushed to the edge of the window and part of it is hidden. (Just
checked with 2002100504 on a linux box)

I suppose that collapsing space wouldn't harm anything. Space does not have to
be preserved in headers, right?

Comment 218

[Peter Lairo]

The "fix" for this bug unfortunately made things *worse* than they were before.
The subject rarely (if ever!) was the cause of this bug. 

Ironically, the main cause of this bug - namely long e-mail addresses - remains
unfixed.

Also, the bug to reinstate subject line wrapping (bug 166892) has been dead in
the water ever since it was filed.

Please, Please, Please reverse the patch for this bug (since it doesn't fix
anything anyhow) until a solution is found that doesn't break subject line wrapping.

Comment 219

[Jon Roland]

I have found an instructive message that causes this problem in Build
2002082611. It is a multipart MIME which combines the text and HTML versions of
the message, for which the mail client is intended to display the HTML part if
HTML is selected as the viewing mode. Subject and email addresses are not very
long. Has attachments. It not only causes the scrollbars to disappear in the
message pane, but causes the settings for the fields to be displayed in the
message listing (I have Subject, Sender, Date, Size and Flag) back to the
default settings of just Subject, Sender, and Date. One can view the message by
switching to text mode and using the PgUp/PgDn keys or the mousewheel. If anyone
is interested, I can send the message for diagnosis. The problem also appears if
one double-clicks to get the message in a new window.

It would seem that the solution would be to make the message viewing pane/window
a complete browser display. This problem doesn't seem to occur when browsing the
same HTML, if it is saved to an external file, stripped, and then viewed with
the browser.

Comment 220

[Colin Blake]

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

Comment 221

[laurel]

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

Comment 222

[Kevin McHale]

Attachment: screen shot

Screen shot of the bug on W2k caused by long list of cc recipients

Comment 223

[laurel]

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

Comment 224

[Bill Fraser]

Attachment: simple example where path is too long in newsgroup messages

On my ISP's news server (nntp.ix.netcom.com), every message does this due to a
long 'path' header.

Comment 225

[Adam Macznik]

I don't understand why people insist on keeping this bug open. It has been
fixed. Period. Noone promised it won't show if you use screen resolutions like
640x480...

Re: comment 222: I don't see this bug on the provided screenshot. In fact, I
don't see anything wrong on this screenshot...

Re: comment 224: The screenshot shows _this_ bug, but I can't reproduce it
anymore, since the patch has landed. Paths in news posts appear in textboxes
like anything else. What build you were using, Bill?

Comment 226

[John Malmberg]

This bug is still easily reproducable on:

Mozilla 1.2b

Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.2b)
Gecko/20021022

Comment 227

[Scott Davis]

The bug is still present (for long To/Cc addresses) on SPARC/Solaris8 using
nightly build 2002110622, although not as extreme as previously, as now the
left-hand panel (folder display) collapses to only showing fiolder icons and
ellipsis before pushing the scrollbars/attachment list off the right side.

An effect of this resizing of panels is that there is a LOT of flickering and
redrawing when changing from one mail message to another, as the panels need to
resize and be rerendered,and it all seems to happen several times as they sort
out their relative sizes.

I typically have the mail window about 700-800 pixels wide, so I can also see
other windows on my screen, and frequently get mail with attachments and email
addresses long enough to show this bug.

Comment 228

[Ian Nartowicz]

This bug has been alleviated (as of 1.2b), not fixed.  The scrollbars and
attachment window still disappear, just less frequently than they did before,
for me at least.  Now, I find the pane jittering and difficulty manually
resizing the panes a significant problem.

Comment 229

[Anant Sahai]

Attachment: A 1.2 shot showing the folder-list being squashed to unusable size by the message preview

This bug has been around for me for a while and it still present in the 1.2
Linux build released yesterday 11/26/02. The bug makes it impossible to drag
and drop a message into a folder as well as making it impossible to use the
scrollbars.

Comment 230

[Aaron Lawrence]

WHY OH WHY... does the content of the header cause ANY resizing at all?

I suggest the headers panel be a small HTML view that uses normal HTML to
display bold, mailto's etc. 

This would 
a) mean that the thing never resized depending on it's content 
b) allow the whole thing to be copied as one piece, or selective parts of it
(for example a part of an email address)
c) standardise all the actions on email addresses 
d) make it really simple 
e) Provide a scrollbar for the header if it was really long

It's annoyed me for some time that the headers are so restrictive, and then I
had this bug where it started hiding things and resizing :( why not cut through
all the crap?

Comment 231

[home]

I am getting the problem in 1.2.1 for long to or cc headers.

I think that (disableable) tooltips would be a good idea for these long headers
(including the subject header which appears to have been otherwise fixed).
Either that or a discrete arrowhead for dropping down a dialog with the full
(wrapped) header. The latter may look more professional.

Comment 232

[Kurt Huwig]

People keep sending me URLs in subject with an empty body; I cannot cut & paste
text in tooltips, so this would be a disadvantage for me; expandable subject
line sounds good.

Comment 233

[Ian Nartowicz]

Does anyone else experience the spastic thrashing and pane resizing whenever
they mouseover a menu or toolbar button?

Comment 234

[Scott Davis]

Only when the pane is squashed by a wide address header and attachment box.

Comment 235

[Ian Nartowicz]

Attachment: Cut scrollbar

Here is a case where the folder scrollbar is cut off.  Also, the status bar
disappears.  It is caused by a vertically long expanded header.  Build ID
20020208.

Comment 236

[Ian Nartowicz]

Sorry, typo.  I meant 2002120208.  It still happens in 2002121008, latest nightly.

Comment 237

[Felix Miata]

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

Comment 238

[lloyd]

time to update the target milestone for this bug?  still reads 1.2b

Comment 239

[laurel]

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

Comment 240

[John Malmberg]

The resizing of the preview window based on the header content is very anoying,
and it seems to take the news client several tries to come up with one that fits.

My preference is that I set the size of the windows, and sub-windows, and if the
content does not fit, I should be able to scroll it, manually resize the window,
or click on a button to display the expanded content.

Comment 241

[Vincent Hamrick]

I have been seeing this problem for quite a while and it happens whenever long
addresses are in the CC fields.  I agree with comment 240 about fixing the
address and attachments block sizes, except instead of letting the user set the
size set them to 2/3 and 1/3 of the current window size respectively.

Thanks,

Comment 242

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 243

[wallycrooze]

Attachment: Addresses longer than the default width of the message pane resize pane

The attached offending e-mail was a result of importing from outlook. The two
support e-mails are duplicates with the "To:" list corrected, to help prove the
point.

Comment 244

[Felix Miata]

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

Comment 245

[Roland Lammel]

We started using mozilla on HPUX 10.20 with 0.9.4 and the only thing left to
convince us to switch all hp-ux workstation user over (around 120) is the quite
unusable mail client. Although it is slow, this bug makes it really unusable as
the resizing of the panel takes around 2-8 seconds to complete. 

As we have a lot of long email_aliases and long names about every mail with
attachment leads to that problem.

So from my point of view (although very biased of course, through bad
experience) this should be a blocker for 1.3

Comment 246

[Andreas Kunz]

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

Comment 247

[M.Paugh]

(Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210)

I don't know if this is the correct bug to make this note, but
this isn't limited to mail and news.  This behavior will occur
anywhere in the browser.  From what I can tell, Mozilla is
sizing its GUI content to the wrong width in certain situations
where it thinks its window is larger than it is.  The right
scrollbar needs to be locked to the right edge of the window but
it's actually locked to the right side of the GUI content in some
cases...  Another way to reproduce this:

1) Install the pref bar (http://www.xulplanet.com/downloads/prefbar/)
2) Open the pref bar's "Customize" panel and start adding buttons
   to it until the buttons go off the right side of the window
3) Edit the label of one of the buttons currently on the pref bar
4) Hit "OK" and notice your right vertical scroll bar has gone bye-bye

If you then resize the window so that the entire contents of the
pref bar fit, the scroll bar comes back.  The scroll bar hasn't
actually gone anywhere, it's just Mozilla has gotten confused
about the size of the window, and has scrolled the scroll bar
right off the window.

Restarting the browser will fix this for a while--meaning the
scroll bar will be in the correct place even if the pref bar
contents are clipped off the right side of the window.

Might be a bug in the pref toolbar, but it seems to me Mozilla
simply gets confused about where the edge of the window is.
(This also affects the toolbar with the throbber as was mentioned
in comment 9.) From what I can tell, this occurs if at
any time any aspect of the Mozilla GUI (e.g., the menu bar, any of
the toolbars, etc.) is assigned a width that differs from the width
of the window.

Comment 248

[Kendall Lister]

Sorry if this is already known (I read most of the comments for this bug, but
seriously, there is more than 18 months worth of discussion here!). A very long
header field (e.g. Cc:), combined with an attachment, cause the whole mail pane
to expand slightly (the section of the mail application that contains the list
of messages in the current folder, the header and the message content). The list
of folders on the left of the Mozilla Mail window is shrunk to compensate the
expansion of the message pane. This is particularly noticable when stepping from
one message to the next, because the Mozilla window "shakes" before settling on
the new size. It's very disconcerting, although no functionality is lost.

Comment 249

[Malcolm Turnbull]

Window size jumping all over the place when reading messages...

I just came across this in Moz 1.3 (windows & Linux), I thought it was a MAJOR
bug until I realised it was only one message in the inbox causing a problem.
The from field had :
NAV for Microsoft Exchange-CRO+AF8-EXC+AF8-02 <[e-mail]>

Could we not allow a line break before the <NAV... bit ?

Comment 250

[Leonardo Morelli]

okay everyone, I am going NUTS with this one. It's nothing like any images on
this thread, but I've been coping with this fault for a couple of months now,
and I tried looking at every option, every bugzilla thread, and found nothing.

Whenever I open a message, I don't see the standard header you all do (like a
bar with the address, subject and an attachments windows if there are any - in
fact, this is the bad part).

see a screenshot here taken with mozilla 1.3  - it will speak better than many words
http://www.studiowares.com.br/cyx/other/images/mozillamail_noheader.png
the message showing on the mozilla mail window has an attachment called
"meditar.pps", and I can't save it at all - not even going to File, Attachment,
Save all - it tries to save the file with no name, and when you give it a name,
it fails. I sent the same message to another mail account and download it with a
new profile, everything looked fine.

Tried deleting prefs.js, XUL.mfl, all to no avail. When I created a new profile
and tested, everything was how it should be.

However the message display doesn't actually look like a bug. Is there an option
to make it look like mine? Where the hell is it? How the hell did I turn it on,
since I never wanted to? So I am posting this here, someone else could be
experiencing it.

Comment 251

[Mitch]

In response to #250's comment's, apparently deleting your addressbook files
solves the wierd non-xul header problem you are seeing in your screenshot.

One of our users was experiencing the same problem and there's a bug logged
somewhere in bugzilla's bowels which you may be able to find referring to this
issue.

Comment 252

[John Gerth]

I'm now using Mozilla 1.3 final and this bug shows up all the time
as I try and debug installation of a new MTA for site.   In doing
so I want to see all the mail headers and so choose:
         View->Headers->All
After that, whenever the message pane is viewing the expanded headers,
it's very easy to lose the scroll bar on the message pane and
thus render it useless until one either collapses the headers
or moves to a new message. Interestingly the headers rendered
on the gray background seem not to be truncated enough to allow
for the existence of a scroll bar. It looks like the only
place a scroll bar would be allowed is in the message body
which would explain why once the headers become large, you
lose the body and the ability to view it.

Comment 253

[robin webbe]

Something very much like this happens with my Mozilla 1.3 mail client.  The
message text on certain messages either isn't displayed ever, or after 1st
viewing  , vanishes.  Any scroll bars vanish as does (most of) the attachment
window.  I am running Linux Mandrake 9.1 on an Athlon 1 GHz box.

Comment 254

[Rick Evans]

Indeed, deleting abook.mab makes the attachment window appear again.  Moreover,
by deleting garbage characters from the end of the old abook.mab worked too,
retaining all of my address book entries.
 

Comment 255

[KUROSAKA Teruhiko]

Since I upgraded to Mozilla 1.3, I cannot view the all headers with
View -> Headers -> All because of the symptom described in this bug.
The only difference is it happens for all the messages.  (Because of
the spam detection software, all the messages I receive have many
headers.)  I am using Mozilla on Windows 98 SE Japanese.

Comment 256

[Mirek]

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

Comment 257

[Emiel]

My description for this problems is:
When an e-mail is send to multiple people separated with only a semicolon, the
mail program tries to put them in 1 line on the screen.

This causes the columns of the Date, Status, Size, etc. to disappear. Also the
tree at the left is resized to a small unreadable space.

The tree is not resizable anymore.
For some reason the long "To:
[e-mail];[e-mail];[e-mail]"
is not broken into several lines. 

Comment 258

[[e-mail]]

I thought email addresses had to be comma separated. Anyone got an RFC?

Comment 259

[Kurt Huwig]

Comma is mandatory:

RFC822:
     4.  MESSAGE SPECIFICATION

     4.1.  SYNTAX

[...]

     destination =  "To"          ":" 1#address  ; Primary

and:

    2.7.  #RULE:  LISTS

          A construct "#" is defined, similar to "*", as follows:

                              <l>#<m>element

     indicating at least <l> and at most <m> elements, each  separated
     by  one  or more commas (",").

Comment 260

[Mike Cowperthwaite]

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

Comment 261

[Yves Masquelier]

RESCUE METHOD TO RETRIEVE ATTACHEMENTS
The conditions which involve the disappearance of the attached files are unknown
to me and I undergone them. But, while seeking a little, I found a method to
recover them without another tools that the mail of Mozilla itself.

2 files seem, by miracle, intact for both the user and the local files, they are
the Templates and Drafts folders.

Just carry out a copy (not a move for security) of the mail in one of these
folders (use Drag and Drop with the control key pressed). Then open the mail in
an independent window (double click on it's name). Your mail is open, like for
Edit it, and your documents will appear in the window of the attachements. When
the mouse passes on the name of a document its temporary storage location
appears in a bubble-info (usually C:\WINDOWS\TEMP with a name like nsmail.ext -
nsmail can be suffixed with minus and a serial number if there is many attached
documents with the same extension).
You can now recover the documents.

Comment 262

[Yves Masquelier]

RESCUE METHOD TO RETRIEVE ATTACHEMENTS (more simple)

Just right click in the mail and select 'Edit as new...'. The mail is now opened
in an independent window like for Edit it, and your documents will appear in the
window of the attachements. When the mouse passes on the name of a document its
temporary storage location appears in a bubble-info (usually C:\WINDOWS\TEMP
with a name like nsmail.ext - nsmail can be suffixed with minus and a serial
number if there is many attached documents with the same extension).
You can now recover the documents.

Comment 263

[Mike Cowperthwaite]

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

Comment 264

[Mike Cowperthwaite]

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

Comment 265

[Brent]

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

Comment 266

[Peter Lairo]

Modifying Subject because this bug has morphed:

OLD: Long strings in mail or news header cause scroll bars and attachment window
to disappear, making message unreadable

NEW: Long Strings in Mail/News Header causes Folder Pane to Resize and/or Jiggle

Comment 267

[Peter Lairo]

Darn, forgot to actually CHANGE the Subject. Sorry for bugspam. :-[

Comment 268

[Peter Kirk]

I don't agree that the new subject captures the essence of this problem, at
least from my own experience (bug 210600). I see three things as happening here:

1) Long Strings in Mail/News Header causes MESSAGE (not folder) Pane to Resize
(not sure about the jiggling);

2) Resizing of message pane causes resizing of other panes;

3) Resizing of message pane, if this pane becomes too wide to fit on the screen,
 causes scroll bars and attachment window to disappear, making message
unreadable. In this case I don't even get a horizontal scrollbar, in any of the
many affected panes. This is a separate bug - maybe bug 151831 or similar.
Fixing this issue would go a long way to mitigating the seriousness of the main
bug as the message would then be readable if only with horizontal scrolling.

Comment 269

[Ruth Milner]

[e-mail] wrote:

> I don't agree that the new subject captures the essence of this problem, at
> least from my own experience

I'll second this statement. While the folder pane does sometimes get squished
to the point of unreadability, the biggest problems that are *due to the
header pane* are:

 1. long header strings, even when they have spaces, overflow the right edge
    of the header pane (note: the patch that made it possible to copy header
    text also made it possible to scroll individual header lines, but it's
    not at all obvious to the user that it can now be done)
 2. messages with many headers, e.g. from list management software, overflow
    the header pane *vertically*, making the message body below and/or the
    folder contents above too small to use; any remaining headers that
    fall off the bottom are also inaccessible

I run at 1600x1200 with Mozilla full-screen, and see these problems daily.

The bugs could be mitigated, at least for people who can manage with a
smaller font, by allowing the font size in the header pane (all of the
panes, preferably) to be customizable, as it is in the message body. But
that wouldn't fix them, just reduce the number of messages triggering them.

Maybe there are actually two bugs here, and not all of the bugs marked as
duplicates really are? That might explain why the bug seems to have morphed
even though the originally-reported problems are still there.

Comment 270

[Mathias de Riese]

I see the problem on a lot of mails with short Subject and short Filenames in
the attachment field and usually a few moderately long entries in the To:
section, e.g:

Michaela Angermann <[e-mail]>

It seems to be related to the automatic change in size of the Mail Pane.

A workaround for users would be to collapse the whole header. But thats not
nice. It is especially annoying when scrolling thru the mail index: On my slow
machine it takes 3 seconds to calm down entering or leaving a problematic message.

Comment 271

[Charles Fenwick]

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

Comment 272

[George]

I get this too, but in my case its inexplicable. There is violent jiggling of
the inbox folder view in Mozilla Mail client and eventually this process ends up
haning my PC and taking up 100% of cpu usage. The only option is then to
hardboot. I have noted this fault in both Windows Xp and W2k03.

It happens when the mail box is full, when it is empty, when I have just
recieved mail or when there is no new mail. There is no direct pattern to it.

It is no longer possible for me to use Mozilla mail at this time.

It worked in 1.3, but 1.4 has broken it.

Q

Comment 273

[George]

This happens to me also, or very similar. For no reason whatsover (well for no
pattern) opening mozilla mail will cause the inbox view to vibrate violently
back and forth. It happens when I just launch mozilla mail, when I just recieved
mail, when I have no new mail, when my mailbox is empty and when its full. As I
said it appears completely random.

I am no longer able to use Mozilla mail at this time.

Q

Comment 274

[Peter Kirk]

I agree with the final part of comment 269. The bug reported in comments 272 and
273 seems quite different from what I am seeing. George sees vibration of
windows at random times even displaying an empty mailbox. I see different
symptoms in different circumstances: stable resizing of windows, with no
vibration, when I click on mail with specific properties, extra long recipient
fields. These must be different bugs. I hope this bug isn't becoming a dumping
ground for miscellaneous display problems which annoy lots of people but look
hard to fix.

Comment 275

[Peter Kirk]

Attachment: The problem as Peter Kirk sees it (black added for security)

Comment 276

[Ian Batterbee]

Can I just get a clarification - Peter Kirk, comment 274 - in the attachment you
just sent, the first 9 toolbar icons are distorted.. it looks like it is
probably due to mapping down to 16 colours, and the next - print - is almost
completely missing, and the stop icon is gone.

Is that simply due to the gif attachment being reduced down to 256 colours (or
maybe 16, and then saved as a 256 colour gif), and are the missing stop and
print icons related to the same problem, or is that really what you see on your
screen when the problem occurs ?

Also, it looks as if you have large fonts (120dpi) enabled in windows - is that
correct ?

Comment 277

[Peter Kirk]

Some of the distortion is indeed due to reducing this to a GIF. I can send the
full BMP privately if you would like me to. But on my screen, ever since I
enabled them, the Print icon has been mostly missing and the Stop icon
completely absent. Another bug which I hadn't bothered to report yet.

I have enlarged the text size because the default comes out unreadably small on
my 1400x1250 laptop screen.

Comment 278

[Ian Batterbee]

I've been trying to replicate this problem here and no matter what I do, I can't
get it to fail any more. I'm running the 1.4 release, 1600x1200, normal font
size, and I created a message in my inbox (using vi) with a 3800 character CC
line all on one line. Viewing the document source verifies that it arrived at
mozilla on on one line.

Does the long line have to exist in a particular header for this problem to
occur now ? I notice in the example Peter uploaded that it was a BCC line that
was very long, so I assume he was looking at something in his Sent folder as a
BCC line should not exist in an incoming email.

Has anyone got an absolutely fool proof way of reproducing this problem right
now in mozilla 1.4 ? It would probably pay to include screen res, font size, and
what lines are in the header of the offending message.

Comment 279

[Peter Kirk]

Attachment: A message displaying the bug as Peter Kirk sees it

The attached message causes the problem consistently for me, on my 1400x1050
screen (with enlarged characters, but I was getting the same problem with other
messages when I had smaller characters). Of course in this case I have not
given any place where the line could be broken, but with imported messages the
lines are not broken even where there are spaces. This is perhaps because the
entire lines including spaces are parsed as a single address - note the
continuous underline under the address list in the screenshot.

So perhaps two bugs, or features, are interacting and causing this problem:
1) lists of addresses on one line separated by commas are parsed as a single
address;
2) single addresses longer than one line are not broken, even at spaces, but
cause the window to expand in width without limit.

I have noted other problems with the parsing of lists of addresses.

The message shown in the previous attachment (with BCC's) had been imported
from Outlook 2002, probably indeed from its Sent folder. But I get the same
problem with To, CC and BCC lines.

Comment 280

[Ian Batterbee]

I can confirm that the problem occurs for me with Peter's attachment, so it's
not something specific to his configuration

I can also confirm that if I edit the message I manually tweaked a couple of
comments back (that previously caused no problem), and remove the commas and
spaces from the addresses so that it becomes one huge long unbreakable line,
then the problem does occur.

So this bug seems to occur specifically when moz can't break the long line at
whitespace.

In Peter's case, it looks like there's a(nother) bug in the outlook importer
that creates very long unbreakable lines.

Comment 281

[Ian Batterbee]

Apologies for the bug spam, but I just noticed one more thing - while a problem
message is displayed, the pane will resize back and forth whenever the mouse
moves over (or leaves) the "Get Msgs" toolbar icon, or over a clickable link in
the body of the displayed message (such as a mailto: link, an http: link, or
something that moz thinks looks like an email address)

This behaviour may help to explain why some people have been reporting sporadic
resizing where they said they didn't do anything - they may have moved their
mouse over something that triggered the redraw event.

Comment 282

[Peter Kirk]

On comment 281: I get this too.

On comment 280: I edited my test message to insert spaces in the long address I
typed in before, dividing it into separate "words". Mozilla has added commas
between each word in the address, and some new lines, and now treats each word
as a separate address. The commas are already there in the source in "unsent
messages" and so were presumably added when I pressed "send later". But even
when I edited the mailbox file to remove the added commas and new lines, closed
Mozilla, deleted the .msf file and reopened, the address line is still parsed as
multiple addresses and broken between these addresses; obviously a space in an
address line is considered a separator and a line break possibility.

So why isn't this happening with my messages imported from Outlook? The long
address line here includes many spaces but it is parsed as one long address
line. They are real spaces, not hard spaces. The line in the source consists of
a number of items mostly in the format "John Doe ([e-mail]);" but Mozilla
displays only "[e-mail]". Some items are in the format "John Doe (John
Doe);"; Mozilla displays just "John Doe", but does not split at this space.
Well, I see that's not the full story. I did a test from which I see the
following result from parsing:

Line in the source (I really changed real names to all x's to protect privacy):
BCC: xxx xxxxxxxxxxxxxx ([e-mail]); xxx xxxxxxx
([e-mail]); xxxxxx & xxxxxxxx xxxxx ([e-mail])

Display as single, unwrappable e-mail address (recreated as I couldn't copy this
line - all with a continuous underline):
Bcc: [e-mail] [e-mail] [e-mail] <xxx
xxxxxxxxxxxxxx ; xxx xxxxxxx ; xxxxxx & xxxxxxxx xxxxx>

When I edit out of the source line all the parentheses, the source line is now
parsed so that each space separates a new address. From some further testing, it
appears that the presence on an address line of just pair of parentheses, as
long as they contain at least one non-space character, is enough to trigger a
different line parsing mode in which only commas, not spaces, are recognised as
address separators. This may be sensible, but unfortunately it conflicts with
the results of importing from Outlook, which include parentheses, but use
semicolons, not commas, to separate addresses.

Proposed patch, which will very simply solve the worst of this bug (though not
the problem with window resizing when a single address is REALLY too long to fit
in the window): edit the routine which parses addresses containing parentheses
so that it recognises semicolon as well as comma as an address separator.

Comment 283

[Andrew E. Mileski]

This is NOT the same bug as I reported and was marked as a duplicate.

I just want to see ALL headers without truncation.

Comment 284

[Ruth Milner]

Reading the comments shows that there are many diverse symptoms:

- scrollbars getting truncated (pushed outside the window so they are
  invisible)
- various parts of text ditto, especially long headers
- message body and message/thread list getting squashed vertically by
  header pane to the point where they become invisible or unusably small
- folder list getting squashed horizontally to the point of unusability
- maniacal pane jiggling as a result of resize

and more.

The only thing in common with these is that they are all related to the header
pane automatically resizing. These symptoms have been around since before
1.0, so clearly getting resizing to work correctly in all cases is a very
hard problem. Is it not possible to define a maximum limit on the pane size,
both vertically and horizonally, and then use vertical and horizontal
scrollbars on the header pane when it would exceed that?

I'm submitting an attachment showing two of these problems:

 - long Received (and other) headers truncated at edge of pane
 - numerous headers causing header pane to resize so large that it wiped
   out the body of the message below

Comment 285

[Ruth Milner]

Attachment: long headers truncated, numerous headers wipe out body

Ignore the low-res blurred fonts, I did that to keep the file size small.
Symptoms are plainly visible despite this.

Comment 286

[Michael Cooper]

I have recently installed Mozilla V1.4 running on Windows-XP and now have this
jiggle problem.  I tried to reinstall V 1.3 from the net but that failed.  So
now it's V1.4 with the jiggle or change product :-(

Comment 287

[Craig Ringer]

Hi folks

Just letting you know that bug 131733 may be related - probably in part a dupe
of this, bug 201379 and bug 201460 but not entirely.

A quick suggestion, though: At least for handling ultra-long subject (and From:
address, these cause the same problem) lines, perhaps a truncated header and a
tooltip would be the way to go?

"Bob ... <bob@ ...>" with a tooltip that displays the rest? This is fairly
common UI behaviour in many apps now, so it shouldn't confuse users too much.
Surely not as much as the message pane going nuts!

Comment 288

[Bryan W. Headley]

What's important is that determining the size of the strings being displayed
should not (or at least should have an option so it does not) attempt to resize
it's container widget. It puts up vertical or horizontal scrollbars, and that's
it. The only way "jittering" should occur is if the container is physically too
small to display a sub-window of XxY characters AND one to two scrollbars. Then
it grows to that absolute minimum size, puts up the scrollbars, and sits there.

I personally don't like tooltips because they're frequently miscoded and avoid
the issue. 

Miscoding: they're often unaware that their width, plus starting coordinate wrap
off the visible area of the display. 

Problem Avoidance: they don't deal with the fact that the string could be so
long as to wrap from monitor's left-most coordinate to right-most, yet cannot
display the whole string. "Oh, it cannot happen." Yes, it can, and that's why
you use tooltips for messages whose length you can control, whose value no-one
would want to select-copy. 

Just my $0.02.

Comment 289

[Craig Ringer]

I can definitely see your argument about tooltips - however, what alternatives
are there to display over-size strings? Scrolling fields are very clumsy, fields
that wrap cause other problems (pushing the message body off the bottom of the
screen), and just truncating the contents isn't really an option.

A tooltip that's smart enough to wrap may be the best of a bad lot. The ideal
solution, of course, is REASONABLE HEADER LENGTHS... but that's a lost hope.

One alternative that'll help with only-just oversize headers is reducing the
font size. That has its own implications on the accessability front, of course.

Comment 290

[Jerry Baker]

Of course, the *real* solution to this bug is to fix bug 9942.

Comment 291

[Ian Batterbee]

Just a comment about a smart tooltip that knows how to wrap itself.. I agree
that it avoids the problem of being wider that the desktop width, but in doing
so, it creates a new problem where it could potentiallly be taller than the
desktop height.

It may be very unlikely that the contents of a tooltip cause it to fill the
screen  entirely, but it's possible that the top left position of the tooltip
may be sufficiently low down on the screen that the tooltip is partially hidden
off the bottom of the desktop.

Just my 2c.

Comment 292

[Bryan W. Headley]

Attachment: A Long Message Header

On the other hand, here is a long message header. I can't snapshot it, but I
can select the text of "Subject" with the mouse, and assuming I move the mouse
to the right, force a scroll-right until the remainder of the field is visible.


Now given that this is doable, What's the harm in two buttons, [<] and [>],
appearing on the left and right-hand side of that view-only field to indicate
that scroll-left/scroll-right is possible? You still manage to keep the whole
thing in one line...

Tooltips to me are extremely annoying when used for anything other than help or
advisory messages: if they have something important in them, and I'd want to
select/copy it's text, forget it... They're often anchored at the wrong place,
so their text "falls off" the edge of the screen, and the disappear when you
don't want them to. So I advise against them.

Comment 293

[Bryan W. Headley]

Attachment: A Long Message Header

On the other hand, here is a long message header. I can't snapshot it, but I
can select the text of "Subject" with the mouse, and assuming I move the mouse
to the right, force a scroll-right until the remainder of the field is visible.


Now given that this is doable, What's the harm in two buttons, [<] and [>],
appearing on the left and right-hand side of that view-only field to indicate
that scroll-left/scroll-right is possible? You still manage to keep the whole
thing in one line...

Tooltips to me are extremely annoying when used for anything other than help or
advisory messages: if they have something important in them, and I'd want to
select/copy it's text, forget it... They're often anchored at the wrong place,
so their text "falls off" the edge of the screen, and the disappear when you
don't want them to. So I advise against them.

Comment 294

[Kalin Kozhuharov]

I was just about to file abou the same bug, when I saw this.

Just compiled 1.5 from source (on Gentoo linux) and doing experiments on bug
#222826 (not related here) I found out the weird auto resize bug.

Just to say, 1.5 still has it.

Comment 295

[Mike Cowperthwaite]

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

Comment 296

[Ruth Milner]

Upgraded from 1.3 to 1.4 a month ago and saw the jitter problem for the first
time today. But it was not related to the length of any headers. It was caused
when the selected folder was at a boundary condition on the need for the
scrollbar in the pane listing folder contents. If it is right at the point where
the list of messages will just barely fit/not fit in the pane, Mozilla can't
make up its mind whether to display the scrollbar or not, and jiggles rapidly
adding/removing it. Folders which clearly do/don't require the scrollbar to
appear don't trigger the behavior. I can turn this on and off quite reliably by
selecting folders that have just the right number of messages to match the size
of folder pane I have set (in my case at the moment, 13-14), or by adjusting the
dividing line slightly.

Note that this behavior is entirely separate from the bug where messages with
many headers obliterate the message body pane, with no vertical scrollbar on the
header pane even when they don't all fit.

Comment 297

[Peter Kirk]

Note also that the behaviour described in comment 296 is entirely separate from
the bug described in my comment 282 and earlier. I saw no jittering, just stable
resizing. So there are at least three distinct bugs here.

Comment 298

[Ruth Milner]

It occurs to me that the appearance/disappearance of the scrollbar in the
message list pane, described in my comment #296, could have been caused by the
header pane resizing so that the list pane alternately shrank and expanded very
slightly; I had been thinking of it as the other way around at the time. Yet it
happened reliably and only when I selected folders which were right at the hairy
edge of scrollbardom; it didn't matter which message I displayed from those
folders, though I had full header display on at the time. It seems to be the
same problem described in 201460.

Perhaps the header pane *always* resizes to fit the headers it's trying to
display, but much of the time the shift is too subtle to notice? There is
overlap between this bug (91662) and several others, e.g. 188138 and 131733. It
seems as though, if automatic header-pane resizing simply didn't happen, an
awful lot of the problems described in many threads would have no trigger.

Comment 299

[Mike Cowperthwaite]

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

Comment 300

[Mike Cowperthwaite]

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

Comment 301

[Matthias Bockelkamp]

Comment on attachment 76566 [details]
Image of my mozilla mail window with the formatting broken.

This part of the bug is already fixed.

Comment 302

[Matthias Bockelkamp]

Comment on attachment 76567 [details]
A message in the same list which doesn't have an attachment.

This part of the bug is already fixed.

Comment 303

[Matthias Bockelkamp]

Comment on attachment 80749 [details]
Better screenshot of this bug showing also desktop as reference

This part of the bug is already fixed.

Comment 304

[Matthias Bockelkamp]

Comment on attachment 85402 [details]
the vertical splitter crossing the scrollbar of the mail folder listbox

This part of the bug is already fixed.

Comment 305

[Matthias Bockelkamp]

Comment on attachment 85403 [details]
a screenshot of this bug under windows 98

This part of the bug is already fixed.

Comment 306

[Matthias Bockelkamp]

Comment on attachment 96619 [details]
screen shot of an email with a long subject, and an attachment.

This part of the bug is already fixed.

Comment 307

[Matthias Bockelkamp]

Comment on attachment 43017 [details]
make a local folder with this email to see the problem

This part of the bug is already fixed.

Comment 308

[Matthias Bockelkamp]

Comment on attachment 43102 [details]
better test case

This part of the bug is already fixed.

Comment 309

[Matthias Bockelkamp]

Comment on attachment 43102 [details]
better test case

This part of the bug is already fixed.

Comment 310

[Matthias Bockelkamp]

Comment on attachment 63515 [details] [diff] [review]
62514 broke collapsed headers, sorry

This part of the bug is already fixed.

Comment 311

[Matthias Bockelkamp]

Comment on attachment 89053 [details] [diff] [review]
Revised email address patch

This part of the bug is already fixed.

Comment 312

[Matthias Bockelkamp]

After trying to strike out obsolete comments on my printout, I found that I was
too fast in marking attachments 43102 and 89053 as obsolete. I'll undo that. But
a new idea: Would it perhaps be better to convert the whole hbox expandedHeaders
to a grid like collapsedHeaderView? That would also close Bug 126071 forever,
which still needs a patch from time to time.

Comment 313

[Matthias Bockelkamp]

Sorry, It seems I now deleted the URL...

Comment 314

[Matthias Bockelkamp]

Attachment: hbox -> grid, needs work

Comment 315

[Mike Cowperthwaite]

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

Comment 316

[Ben Bucksch (:BenB)]

I'll try to take a stab at this.

I think we're seeing 2 different bugs here at work. The fact that the splitter
jiggles is strange. The whole purpose of the splitter is to allow the user to
*set* the size, so it should stick with it. The "content" (i.e. the 2 sides of
the splitter) should have no effect whatsoever on the position of the splitter
or the container, just like the content of a window doesn't resize it. That the
splitter changes at all (due to changes in the content) is a bug in the XUL
splitter implementation for me, not a Mailnews bug, and I filed bug 241253 about
that.

Thanks to a hint from Neil Parkway, I noticed that the fix by Stefan Borggraefe
for bug 63654 also fixes this part of the bug. In my tests, the splitter remains
unchanged regardless of the header bar content.


The other part of the bug is still left: Long addresses, esp. with attachment
box, extend the thread pane and msg pane bejond the egde of the window, making
the right side invisible.

Comment 317

[warren reier]

I may have seen this same behavior with the Google regular search.  I used the
advanced search, but when the results are returned, there is an entry field at
the top of the page for another query.  If I use that, I get a screen that jiggles.

Comment 318

[Mike Cowperthwaite]

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

Comment 319

[Ben Bucksch (:BenB)]

s/Neil Parkway/Neil Rashbrook/

The mentioned fix for bug 63654 is now checked in, fixing most of this bug, too.

> The other part of the bug is still left: Long addresses, esp. with attachment
> box, extend the thread pane and msg pane bejond the egde of the window, making
> the right side invisible.

This remains true. Because this bug is such a total unreadable mess (it took me
a whole working day just to read over it! :( ), I filed a new bug about that:
bug 247833. I'll dup this bug against that. I'll comment here once that bug is
fixed, to notify people who are cced here.

Also compare bug 9942.

*** This bug has been marked as a duplicate of 247833 ***

Comment 320

[Matthias Bockelkamp]

v