223340 - Multiple attachments cause excessive size in attachments pane

Status: VERIFIED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[rich cowan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla Thunderbird 0.3

I subscribe to the Riders email list (a sympa list) located at:
http://npogroups.org/lists/info/riders-tech

I have my email preferences for the list set to Digest, and I
am reading the mail using Thunderbird. What is happening is
that the mail messages are showing up in the body and also
as separate attachments. This just seems wierd. Perhaps
they should be labeled as something else, not as Attachments.
Because an email digest can contain real attachments too.



Reproducible: Always

Steps to Reproduce:
1.  Subscribe to riders-tech using above url
2.  set the riders tech to digest  mode
3.  check your mail in 24 hours

Actual Results:  
see above

Expected Results:  
I would prefer if Thunderbird would just display Attachments,
and if you want you could just implement this as a tabbed
interface:

/-------------------|
| Attachments |
\--------------- |
| Digest Parts \ |
\-------------------|

So if the user actually wanted to "deconstruct" the digest
into separate messages he or she could do so by clicking on
the tab, but this would not be the default.

this is not really an enhancement; its a wierd UI
design that should be fixed.

Comment 1

[Steve Wardell]

Attachment: Mailing list showing messages as attachments

This shows the problem. I'd like to suggest not removing the showing of
attachments, as they still are attachments just like images are and should show
up in the message, but rather reverting the display of attachments (or an
option to revert) such that they show up in the Message Info line on the right
side (in the To / From area) so they don't take up such a large amount of real
estate in the message area. Mozilla mail shows them up in that area and it
works much better for mailing lists.

Comment 2

[Ben Fowler]

I think that they should show up as thread members and sub threads in the
message selection part of the UI, and yes is should be possible to dissemble
digests by drag and drop.

Ben

Comment 3

[Jo Hermans]

The fact that the individual message show up as attachments isn't a bug, that's
because they are send as separate MIME-attachments. Some mailing list software
(Listserv for example) has to possiblity to choose between sending the digest as
a single message or as multiple attachments. Ofcourse, we can always try to find
a way to improve, for example by displaying the digest as a thread, a folder, or
in a tabbed interface.

See Mozilla bugs bug 147567 and bug 188677.

Comment 4

[Steve Wardell]

Two simple possibilities that would make this much less of an issue:

1) Default to showing 1 or maybe 2 lines of attachments and all toggle between
show all and show the first few
2) Allow resizing of the attachments window and store the resized value so
messages with attachments always show with that size attachments window

Personally, my main issue is that when I get certain mailing lists it takes up
like 1/3 of the screen vertically with the attachment area, so reading the
message is more difficult since I usually read messages in the preview pane.

Comment 5

[Robert Accettura [:raccettura]]

Well, I 100% agree that this is an issue.  I have several mailing lists
digested.    I also do on occasion get several attachments to an email.

I have a hi resolution screen (1400x1200).  I'd hate to see what this is like on
an 800x600 screen.

The previews on the Mozillazine forums when this feature was in the works made
sense.  But there needs to be some sort of toggle, or just scroll bars to
prevent this from happening.  My attachments pane takes up most of the normal
message body space.

Comment 6

[Robert Accettura [:raccettura]]

It's more than just email digests.  So the summary "Email Digest shows up as
many Attachments in Thunderbird" isn't quite descriptive enough (I almost filed
a dup)

Comment 7

[Steve Wardell]

This continues to be a major hinderance to reading of many mailing lists.
Additionally, it could probably be an issue for viewing of attached webpages
with multiple graphics. Proposing the following:

1) Don't let attachments area grow beyond showing 2 rows for default size.
2) Add resize scroll drag bar / scrolling drag to scroll through the list of
attachments to allow showing more.

If the above would be difficult or problematic, the minimal level would be to
allow clicking on the bar or somewhere in attachments to not show any
attachments for that current message.

Comment 8

[Steve Wardell]

Scott: Can we address the most basic aspect of this issue through either the
ability to resize or ability to "minimize" the attachments area in a message?
This makes reading some mailing lists extremely difficult. Thanks.

Comment 9

[Tuukka Tolvanen (sp3000)]

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

Comment 10

[Tuukka Tolvanen (sp3000)]

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

Comment 11

[Frankie]

Attachment: screenshot of Bugtraq Digest on a PowerBook

The problem is even worse on a wide-screen display, because this bug is all
about the vertical pixels.

Comment 12

[Mike Cowperthwaite]

xref bug 242531.

Comment 13

[paul stanton]

another vote .. please add some scollbars and allow us to resize panes.

Comment 14

[Mike Cowperthwaite]

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

Comment 15

[Peter Lairo]

Attachment: Screenshot of partial solution (max-height)

Unfortunately, the userChrome.css solution causes the attachments list to
overflow into the status bar. At least it's a start...

userChrome.css:
#attachmentList {max-height: 4em !important;}

Comment 16

[Mike Cowperthwaite]

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

Comment 17

[Seungbeom Kim]

Can anyone tell me why the attachment pane is at the bottom in Thunderbird while
it is on the right side of the message headers in Mozilla Suite? I recently
switched from Mozilla Suite to Firefox+Thunderbird, and I find the Mozilla Suite
way much more elegant and convenient.

Comment 18

[Peter Lairo]

That's better asked in:
snews://secnews.netscape.com:563/netscape.mozilla.thunderbird (set "SSL")

FYI: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 19

[Steve Wardell]

Suggesting blocking since this makes viewing such messages unusable and a
hopefully small change could address (or greatly reduce the severity).

Comment 20

[Steven M Payeur]

I just filed a dupe of this bug (290987), and wanted to add my comments to this
one, before marking it as a dupe:

We could allowed for a hiding or resizing of the attachment list (similar to the
+/- toggle of the email headers or the draggability of the preview window border
in Mozilla's email reader).  

Comment 21

[Steven M Payeur]

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

Comment 22

[Mike Cowperthwaite]

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

Comment 23

[Scott MacGregor]

not a stopper

Comment 24

[Greta]

When viewing the attachments inline, and there are several attachments, nothing
gets viewed inline--the attachments pane is just too big.  I'm adding a vote to
return to the way Mozilla handled it--a scrollable list of attachments in the
right part of the header area.  It's quite likely I'll returnt to using Mozilla
until this is resolved.

Also, it seems bug 288890 is a dup of this bug.

Comment 25

[Mike Cowperthwaite]

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

Comment 26

[Mike Cowperthwaite]

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

Comment 27

[Ruturaj]

the mozilla suite feature of handling (or rather listing) the attachments was
much better than the one of thunderbird

Comment 28

[Bill Gianopoulos [:WG9s]]

Changing severity of this bug.  I recieved a work e-mail which I was unable to
read with Thundebird becasue the attachments pane became large enough so that
the body pane dissapeared completely.  I could find no way to read the e-mail
without reverting to another e-mail client.

Not being able to read an eamil message I would think means a major feature is
broken.

I really do not understand how this can not block 1.5.

Comment 29

[zug_treno]

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

Comment 30

[samuel]

Attachment: A fatal example of this problem.

This is how bad this can get. Notice the complete lack of the body text pane.

Comment 31

[Kyle Guinn]

Placing the attachment list to the top right (like with the suite) would make
displaying a message more consistent with the interface when composing a message
(i.e. attachment list to the right of the headers).

Comment 32

[Seungbeom Kim]

(In reply to comment #31)
> Placing the attachment list to the top right (like with the suite) would make
> displaying a message more consistent with the interface when composing a message
> (i.e. attachment list to the right of the headers).

I agree. And in many cases, listing a series of attachments vertically makes it
much easier to recognize their names than horizontally.

Comment 33

[Bahadir Yagan]

Attachment: attachment pane bug

Opening the e-mail on a new window makes it worst. Attachment pane is larger
than needed. I can't see my self with my new Firefox T-Shirt :). 

This screenshot is from Thunderbird 1.5 Beta 2 on windows.

Comment 34

[samuel]

Attachment: page dump showing outbound email vs inbound email

This is a generated example of this problem. Note that the outbound copy of the
email (did ctrl-e) is properly handled by Thunderbird, so it looks like most of
the code to do this nicely is *SOMEWHERE* in the codebase.

BTW: If you'd like me to send you a copy of this email (about 16k), just email
me a request (samnospam@bcgreen)

Comment 35

[samuel]

Attachment: small sample problem email

append to your mailbox to experiment with the problem (should mess up most
screen sizes, but it's relatively small).

Comment 36

[Adam Guthrie]

There is a reason this bug has its status set to NEW, and that's because it has
been confirmed. There does not need to be any more efforts to "prove" this bug
exists. This includes but is not limted to screenshots, e-mails that display
this bug, etc. Please don't comment on this bug unless you're contributing to a
solution.

Comment 37

[Ray Booysen]

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

Comment 38

[Ray Booysen]

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

Comment 39

[Ray Booysen]

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

Comment 40

[Ray Booysen]

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

Comment 41

[Emmanuel Touzery]

(In reply to comment #33)
> Created an attachment (id=199063) [edit]
> attachment pane bug
> 
> Opening the e-mail on a new window makes it worst. Attachment pane is larger
> than needed. I can't see my self with my new Firefox T-Shirt :). 
> 
> This screenshot is from Thunderbird 1.5 Beta 2 on windows.

i think this is a regression on tb 1.5 compared to 1.0. saw that on 1.5, never on 1.0. also in my case this (attachment pane being larger than needed) does not happen all the time, only 50% of the time. maybe you should retry several times to open the mail in a new big window and if i'm not wrong, it'll be displayed correctly at least once in 4 tries.
I reported https://bugzilla.mozilla.org/show_bug.cgi?id=321325 about that, which was marked duplicate of this mail but i think it's actually a different issue, a regression.

Comment 42

[Martin]

Attachment: Screenshot of Evolution with attachments

Evolution seams to have solved the problem. See screenshot.

On the screenshot you see two attachments, a picture and a text file. Each have a drop down menu, so when you press on it, the picture is shown in a larger size.

Comment 43

[Shaddy Baddah]

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

Comment 44

[Shaddy Baddah]

(In reply to comment #41)
> I reported https://bugzilla.mozilla.org/show_bug.cgi?id=321325 about that,
> which was marked duplicate of this mail but i think it's actually a different
> issue, a regression.
> 


I've just marked a dupe as well, and I agree it. In my opinion, it is definitely a regression. And only it seems, to do with opening saved email attachments (and in this case, opening an email from within an email is surely using the save/open feature to a temporary file).

Comment 45

[Martin]

Attachment: Mock up of attachments having their own column in the Message pane.

Here is a solution suggestion. See attachment.

Comment 46

[Martin]

Attachment: Mock up of Thunderbird with notebook. From Bug about iTunes and GMail layout.

At this mock up ( which comes from Bug #306125 ) do I propose that the notebook
widget is used for Header, Message, and Attachment, and several other could be considered. E.g. a GPG notebook.

I think having an attachment notebook would solve this bug.

Comment 47

[Shaddy Baddah]

I should mention that I now know about a workaround that I previously did not. To put it "on the record", the workaround is to simply resize the message window. You can maximize again if the message window was originally maximized, and the pane sizes are acceptable again.

And by-the-by, why should the attachments of the original message be redisplayed for the contained message? That has always seemed weird to me.

Comment 48

[Bill Gianopoulos [:WG9s]]

(In reply to comment #47)
> I should mention that I now know about a workaround that I previously did not.
> To put it "on the record", the workaround is to simply resize the message
> window. You can maximize again if the message window was originally maximized,
> and the pane sizes are acceptable again.
> 
> And by-the-by, why should the attachments of the original message be
> redisplayed for the contained message? That has always seemed weird to me.
> 

This is not much of a workaround.  As I said in comment #28, I have received e-mails where the attachment pane takes up the entire maximum size window.

Comment 49

[Emmanuel Touzery]

> This is not much of a workaround.  As I said in comment #28, I have received
> e-mails where the attachment pane takes up the entire maximum size window.

the problem is that there are two bugs discussed in this single page. the one Shaddy Baddah was commenting about is at:
https://bugzilla.mozilla.org/show_bug.cgi?id=321325
and was marked as a duplicate. probably it shouldn't have been. that bug is a regression in tb1.5 while what you're talking about is a problem with all versions of thunderbird.
Shaddy Baddah's workaround is interesting for me, for that other bug, i'll check if it works.

Comment 50

[Bill Gianopoulos [:WG9s]]

OK.  Thanks for clarifying.  I unduped the other bug and added a comment to it explaining why the issue there is different.

Comment 51

[Mike Cowperthwaite]

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

Comment 52

[Dirk Schoettler]

Is this duplicate to Bug 157291, too?
Sorry that I beg for clarification, but this bug (223340) isn't about inline attachments anymore (as it started in 2003) but about sizing of the attachment pane, correct?

In that context, may I ask a humble question concerning the GUI-design?
When I open mails with TB (read-only), the attachments are shown at the bottom.
But when I *write* mails with the editor (create or edit drafts), the attachments are listed right from the recipient list (as earlier in Mozilla). At first sight, this seems to be an inconsistent behaviour. What reason to differ? And wouldn't the "old" way like in the editor solve that problem, too? 
(If that's the wrong place to ask, please tell me.)

Dirk

Comment 53

[Mike Cowperthwaite]

(In reply to comment #52)
> Is this duplicate to Bug 157291, too?

No.  For one thing, that bug was about the suite, which has a different style 
of attachment-panel than Thunderbird does.


> Sorry that I beg for clarification, but this bug (223340) isn't about
> inline attachments anymore (as it started in 2003) but about sizing of the
> attachment pane, correct?

Reporter's comment 4 set the scope on this bug.


> When I open mails with TB (read-only), the attachments are shown at the
> bottom. But when I *write* mails with the editor (create or edit drafts), the
> attachments are listed right from the recipient list (as earlier in Mozilla).
> At first sight, this seems to be an inconsistent behaviour. What reason to
> differ? And wouldn't the "old" way like in the editor solve [this bug's]
> problem, too? 

Bug 251811 requests changing TB back to suite-style attachment panel.

Comment 54

[samuel]

Could someone do a quick update on what is holding up this fix?  I'd originally thought that it was a relatively simple fix, but that was over a year ago.  Is it just a shortage of manpower (perhaps someone here could provide that), or is there another bug blocking it in another way?

Comment 55

[Magnus Melin [:mkmelin]]

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

Comment 56

[Mike Cowperthwaite]

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

Comment 57

[Mike Cowperthwaite]

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

Comment 58

[Emmanuel Touzery]

just one comment: there could be a very simple solution to this, even maybe no coding, just pure XUL/css (i don't know XUL). limit the attachment pane to like 200px, then make that a vertical scrollbar appears.
problem solved! i think it's the simplest solution, and it's "good enough".

Comment 59

[Mike Cowperthwaite]

(In reply to comment #58)
> just one comment: there could be a very simple solution to this, even maybe
> no coding, just pure XUL/css (i don't know XUL).

See bug 242531 comment 31 (and other comments there).  IMO, that bug is a dupe of this, but I have been overridden on that point in the past.

Comment 60

[Adam Guthrie]

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

Comment 61

[Mike Cowperthwaite]

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

Comment 62

[Mike Cowperthwaite]

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

Comment 63

[Magnus Melin [:mkmelin]]

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

Comment 64

[samuel]

Yes. I agree that it seems to be a dupe of 242531, but if you're having a problem marking it as a dupe, try marking it as 'depends on', since adding a scroll bar would probably solve the problem anyways. -- and at least you'd establish a link between the two bugs.

Comment 65

[Magnus Melin [:mkmelin]]

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

Comment 66

[Scott MacGregor]

doesn't look like we made any traction on a new attachment UI design for tb 2  :(

Comment 67

[Wayne Woods]

There would be a relatively simple fix except that the css |overflow-y:auto| (presumably incorrectly) overrules the |max-height| setting, so that the attachment box is always drawn at the minimum possible height, which is tiny. If overflow is removed, then it can be sized up to max-height, but then we don't get scrollbars.

At first I thought this was a general problem with css layout in gecko, but the xul testcases I've created, based roughly on the attachmentView layout, actually seem to work correctly. So I still haven't worked out what's so special about the attachmentView layout that violates this.

Comment 68

[Mike Cowperthwaite]

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

Comment 69

[Wayne Woods]

I have a fix for this (and for bug 242531). I'm currently polishing it and will submit it soon.

I've spent a couple of weeks playing with the messagepane XUL and have come to the conclusion that it's like trying to constrain silly putty... you try to squeeze it in one direction so it starts to ooze out another. The main problems are:

1. XUL doesn't support % heights, which is very frustrating. Setting a max-height in px doesn't make sense, as the ideal height depends on what you have your message pane scaled to.
2. If you're going to constrain the attachments box at all, you must have overflow on (auto). But when it's set on, the attachments box is always shrunk to the smallest default size. Switching flex on effects the opposite, and makes it grow as large as possible.

Because of this, I don't believe we can come up with a good solution just using css settings.

The solution I've come up with modifies the script in displayAttachmentsForExpandedView(). It ensures overflow is OFF, then measures the size of the filled attachments box. It also determines a max-height for the box as a fraction of the height of the entire messagepanebox (I'm running it at 1/4 right now). It then hard-sets the attachment box height (as an attribute) to either the original (without overflow) box height, or the max height, whichever is smaller. Then it switches overflow back on. Once the height of the box is set as an attribute, overflow can no longer distort it. To resize, I've added a splitter and grippy as well.

It seems to work well. The only downside is that the user can't set the default ratio (% height) of the attachments box yet. I need to work out how to allow that. I'll post something asap.

Comment 70

[Wayne Woods]

Attachment: First draft patch for 1.9 trunk

First draft patch. Please read below before trying it out:

- As mentioned before, it only fixes the problems with the current attachments box, it doesn't introduce some revolutionary new design.

- Only for the trunk at this stage, though I know earlier trial versions worked on the 1.8 branch, with some fuzziness. But until the patch is 100% right, I'm not going to run two patches concurrently :)

- This patch was created on Mac OS X, which is the only platform I can build on. I've tried to modify the Qute theme file by guesswork, to match what I did in Pinstripe. Basically, remove the top border of AttachmentView and ensure that the splitter has no bottom or side borders, so that it looks like it's part of the top of attachmentView. That's how it looks in Pinstripe. I hope that's how it looks in Qute. If not, I'll need assistance in adjusting the theme.

- The max height that the attachments box will be set to is currently hard-coded to messagepanebox height / 4. Maybe that's too big. Regardless, if anyone has some insight into how to make this ratio a theme-configurable attribute, I'd love to know.

- I've discovered that splitters can really screw with box heights. Those places where I remove the height attribute from the boxes are really necessary.

Fire away :)

Comment 71

[Mike Cowperthwaite]

That's a thing of beauty, Wayne.

I don't see a grippy in my basic vanilla qute/classic version, but the splitter does move as expected.  I think Scott dislikes grippies, so maybe there's some styling here that's keeping it from being seen.

When the attachment panel is sized small, it becomes susceptible to the bug where the scrollbar disappears -- that's a widget problem, but one that will get reported more often once this patch goes in.

The one thing I'd like to see different is, at least for the case where there are more than two attachments, is to put the "Attachments" label above the box rather than to its left.  This would allow three columns of attachments in a "normal"-width standalone message window -- at least, normal for my font sizes etc.  All that space below the "Attachment" label, when there are a lot of attachments, could be better used displaying more attachments.  OTOH, with the message pane of the 3-pane, which I have wider than the "normal" message window, and/or with few attachments, it makes more sense for the label to be to the left.

It would be really cool if the attachment panel could resize dynamically along with the window.  As it is, if you shrink the window, the message body is collapsed entirely first, then the window edge simply rides up over the status bar and then the attachment panel.  This would be much better if the attachment panel could resize first, perhaps to a minimum of one row (xref bug 354748 and bug 41994).

Very nice work!!  Thanks.

Comment 72

[Mike Cowperthwaite]

Attachment: Screenshot: patched version, Win2K + classic/qute theme.

BTW: Anyone else interested in testing this, be sure to remove any customization for this bug you might have in your userChrome.css file.

Comment 73

[Wayne Woods]

Attachment: Screenshot: patched version, OS X + Pinstripe theme

How it looks on OS X. Note that the splitter merges with the attachment box margin to make a continuous whole.

Comment 74

[Wayne Woods]

(In reply to comment #71)
Thanks Mike :)

At least now I can see how it looks on Windows. Your window looks very different to the default theme on Tbird on Win XP, which I use at work.

On Windows, I hoped I could get the splitter to merge with the margin of the attachmentView, as it does in OS X. I'll tinker some more.

> I don't see a grippy in my basic vanilla qute/classic version, but the splitter
> does move as expected.  I think Scott dislikes grippies, so maybe there's some
> styling here that's keeping it from being seen.

Strange, I noticed there was no grippy in the Mac Tb 2 branch, either. But the Mac appearance for Tb 2 looks a bit of a mess right now (even more than the trunk), so I just put it down to "stuff that needs fixing". But maybe it's intentional. I'll have a look. The grippy is useful for getting rid of the attachment box in a hurry, so I'd like to keep it.

> When the attachment panel is sized small, it becomes susceptible to the bug
> where the scrollbar disappears -- that's a widget problem, but one that will
> get reported more often once this patch goes in.

Yeah, that's a shame, but possibly unavoidable. I've tried to find a way in css of telling if a box has a scrollbar, so I can raise the min-height for those cases. But so far, I haven't found a way. Waiting to hear back from Xulplanet forums...

> The one thing I'd like to see different is, at least for the case where there
> are more than two attachments, is to put the "Attachments" label above the box
> rather than to its left.

Makes sense. I'll see what I can come up with. I think it needs to be consistent, i.e. not jump from left to top when the number of attachments increase.

> It would be really cool if the attachment panel could resize dynamically along
> with the window.

Forcing the height to stick by using an attribute was necessary to stop the box taking on a life of its own. Maybe I can do something using flex and max-height, though, but I've never had much luck with that before. I'd rather not resize dynamically inside some function, as it already seems laggy enough.

Anyway, I'll see what I can come up with. Thanks again for your input and kind words :)

Comment 75

[David :Bienvenu]

Attachment: 2.0 safe branch patch.

I applied your patch to 2.0, and tweaked it to get it to apply. I'd love to try to get this into 2.0, though that's really up to mscott...it solves a real usability problem very nicely.

some initial feedback from trying this on Windows - I think having the grippy on msgs with attachments clutters the look a bit, especially in the case where there's just a couple attachments and there's no need to enlarge the attachment view. I think it would be nice to avoid having the grippy if there's no scroll bar, but I don't know how hard that would be. 

If you go from a message with a lot of attachments such that the attachment pane is relatively large, to a message with just one attachment, the redraw is a bit ugly - there are some display artifacts from the previous attachment pane, until the display is finished. This was on a debug build, and there's probably not much we can do about it.

Comment 76

[Mike Cowperthwaite]

In messageHeader.css, I suggest replacing the style block for #attachmentList with this:
===================
#attachmentList
{
  -moz-appearance: listbox; 
  border: 2px inset;
  background-color: -moz-Field;
  color: -moz-FieldText;
  margin: 2px 5px;
}
===================
This is a much more concise way of getting the same border, but more importantly, the very large right-hand margin is reduced -- I suspect that margin was left over from earlier attempts to fit a scrollbar in there.  By reducing both right and left margins, the window doesn't have to be quite so wide to fit an extra column of attachments.  I think the 2px margin on top and bottom looks a little nicer -- the top of the box aligns better with the top of the 'Attachments' label -- but it could be left at 5px if that's too crowded.


(In reply to comment #75)
> I think having the grippy on msgs with attachments clutters the look a bit,
> especially in the case where there's just a couple attachments and there's
> no need to enlarge the attachment view.

You see the grippy?  Do you have any idea why I don't?  (Because you're using a debug build?)


> If you go from a message with a lot of attachments such that the attachment
> pane is relatively large, to a message with just one attachment, the redraw
> is a bit ugly - there are some display artifacts from the previous attachment
> pane, until the display is finished. This was on a debug build, and there's
> probably not much we can do about it.

FWIW, I'm not seeing that.

Comment 77

[Seungbeom Kim]

I really appreciate the great work currently being done by the developers, but if I'm allowed to give a few humble opinions of mine...

1. As mentioned in comment #31 and comment #32, putting the attachment pane on the right side of the header pane (i.e. at the top right corner), instead of at the bottom of the whole message pane, would:
- be more consistent with the composition window,
- make the names of the attached files more easily recognisable,
- make better use of the currently unused/wasted space, and
- render unnecessary the need to deal with the attachment pane size problem at all (because its size is constrained by the size of the header pane).

2. Another idea is: do we really need a separate pane for attachments? I once imagined attachments being just listed at the end of the message body (as hyperlinks, for example), and it may be good enough. No need to deal with the attachment pane size problem, and more space and flexibility at hand to display information.

<example>
... message body ...

Attachments:
* meeting.html (text/html, 20 KB)
* meeting.png (image/png, 314 KB)
</example>
(or they could be formatted as a table, as Bugzilla currently does.)

I hope these idea could help to make a better Thunderbird.

Comment 78

[Wayne Woods]

Hi David,

Any chance you could please provide a screenshot of a window with the grippy? It's hard to visualize when I can't build my own Windows versions. Thanks!

A couple of people have mentioned things that require different styling depending on whether the attachments box is overflowed or not (window height, grippy). I haven't found a way of doing this in css (no relevant pseudo-class or attribute anything). If someone knows a way, please let me know! It's not enough to just determine if the box is overflowed when the attachments are added, because it can change with window resize. So the only alternative that I can think of would be to script it by monitoring window resizing and modifying an attribute whenever the scrollbar status changes. Even if we went for this (probably-costly ?) method, I still can't work out how to get scrollHeight from the box to determine overflow (unless there's a another way).

Putting attachments on the header pane is a worthy idea, but I'm worried that making big changes to the UI at this point would make it much less likely for it to be checked in to Thunderbird 2 (been burned already with Firefox 2), so I just went for a tidy and fix instead. Maybe for Thunderbird 3? :)

Comment 79

[Scott MacGregor]

Attachment: screen shot on winxp for the trunk

wow, this is great work Wayne! I'm very excited.

I'm going to keep running with this over the next few days, but so far so good. This screen shot includes mcow's suggested CSS changes to #attachmentList

Also, I don't see a grippy on the splitter like David is. Trunk vs. branch issue?

The only problem I've seen so far is that I can completely collapse the attachment list by moving the splitter all the way down. I'm worried that users might do this and then think that Thunderbird is failing to show the attachments. Maybe we can force a min height on the attachment box so you can't completely hide it with the splitter.

Very cool!

Comment 80

[Scott MacGregor]

putting back on the blocker list. Wayne has made enough progress with this that I'd like to see if we can finish it off and get it into tb2.

Comment 81

[David :Bienvenu]

I'm sorry, when I said grippy, I really just meant the splitter line itself. I'm not sure what you mean by grippy, actually.

Comment 82

[Peter Lairo]

(In reply to comment #79)
> Created an attachment (id=253139) [details]
> screen shot on winxp for the trunk

The label "Attachments:" doesn't seem vertically aligned with (i.e., higher than) the attachments' filename(s).

Comment 83

[Wayne Woods]

Scott: thanks for your support! :)

David and Scott: it seems I made a mistake about the grippy image. In Pinstripe, the splitter has a small dimple in the middle, which happens to be the same place where the grippy functionality occurs, so I thought that was its image. Turns out that's just the splitter, and the grippy has no image that I can find.
The grippy is still useful, though, as clicking on it can collapse the attachment box instantly. I don't think there's any danger to this: if a user can't work out where their attachments went after the box collapses, the box will reappear as soon as they switch messages (and back again). In theory I could move the "Attachments" label to the splitter itself, but I think that'd made it absurdly fat.

I also now understand what David meant by the grippy (actually splitter) looking too cluttered. When I styled the Qute version, I tried to imitate what I did in Pinstripe (see my previous screenshot), which was for the splitter to replace the top margin of the attachment box, yet look like it's part of the box. Instead, it looks like both the splitter and the margin still have height, with an unwanted border in between. I hope my next patch fixes that (taking a stab at it, anyway).

Comment 84

[Mike Cowperthwaite]

(In reply to comment #83)
> The grippy is still useful, though, as clicking on it can collapse the
> attachment box instantly. 

You mean it's functioning for you even tho not visible?  I'm not getting any such behavior.  Does the cursor change when over the invisible splitter?

> I don't think there's any danger to [a collapsed box]: if a user
> can't work out where their attachments went after the box collapses, the box
> will reappear as soon as they switch messages (and back again). 

xref bug 297006.  I think that, unless there's a specific cue in the UI to indicate the collapsed box, the box shouldn't be allowed to collapse entirely.

Comment 85

[Bill Gianopoulos [:WG9s]]

Perhaps a minimum height just large enough so that the "Attachments:" label is always visible?

Comment 86

[Scott MacGregor]

(In reply to comment #85)
> Perhaps a minimum height just large enough so that the "Attachments:" label is
> always visible?
> 

that's what I was thinking too. Just an idea.

Comment 87

[Wayne Woods]

(In reply to comment #84)
> You mean it's functioning for you even tho not visible?  I'm not getting any
> such behavior.  Does the cursor change when over the invisible splitter?

Yep. When I hover over the (horizontal) centre of the splitter, the cursor changes to a hand. If I click, the splitter collapses.

> xref bug 297006.  I think that, unless there's a specific cue in the UI to
> indicate the collapsed box, the box shouldn't be allowed to collapse entirely.
and:
(In reply to comment #85)
> Perhaps a minimum height just large enough so that the "Attachments:" label is
> always visible?

I've already set a minimum height, at least for Pinstripe, but that doesn't stop the box collapsing via the grippy. I think I'll just have to remove the grippy.

BTW, Enn on Xulplanet introduced me to the onoverflow and onunderflow events, so I can now style boxes according to whether the scrollbar is visible. Problem is that the min-height required so that the scrollbar will be drawn properly (and not en empty gutter, due to the bug) is also the point at which a two-row attachment box (in Pinstripe anyway) is no longer overflowed. So you get a recursive flicker effect as the box jumps up and down in height. I'm seeing what else I can do to avoid this, otherwise we might have to put up with the buggy-looking scrollbar at small heights.

Comment 88

[Scott MacGregor]

Wayne, I'd really like to get this checked in so we can get some wider feedback. According to my notes we need to fix the following with your patch before it can land. Lemme know if you think I'm missing something:

* Use mcow's #attachmentList style improvement
* remove the grippy elements in the XUL
* we need to address comment 84. See if a min height (preferrably the height of the Attachments: label) can be used to prevent users from making the splitter fully collapsed, giving the appearance that there aren't any attachments. (Did attempting to fix this trigger comment 87 about the flicker?)

If we nail those issues I think we can start getting feedback on this by checking it in.

Comment 89

[Wayne Woods]

Sorry for the delay in getting the next patch out, but I haven't been complacent. I discovered the reason why flex was misbehaving so badly here (for some reason, flex on the browser element messagepane is ignored entirely, giving the attachments box free rein). I've managed to get around that by enclosing the messagepane in a simple hbox, and so was experimenting with a different approach: varying flex to control box heights instead of hard-setting them. The benefit of this approach is that the attachment box will resize properly if/when the window does. I have it working, but need one more day to squash a final bug. I'll put it out for testing as soon as I can. If people find fatal flaws, I can very quickly and easily produce a patch using the currently-posted method instead

The points raised in comment 88 are addressed in the new patch, except that setting min-height doesn't stop the splitter from collapsing the box to zero. The only effect that min-height has on the splitter is that when you move the splitter below min-height, the box immediately drops to zero height. The only ways to avoid this (that I can think of at this hour) would be: (a) to remove the splitter, or (b) to stick the label outside the attachments box, such as on the splitter itself (which might make it too chunky). I'll see what I can do.

Comment 90

[Bill Gianopoulos [:WG9s]]

Fixing it the right way now that you have figured out why we could not get flex to work is obviously the way to go.

I would not get too hung up on making it impossible to make the attachment disappear entirely as long as this is all working correctly by moving the splitter.  If someone moves the splitter, they should be able to figure out how to move it back.  I think the issue was that with the other patch there was kind of magic place where you could click that would make it disappear.  If you can avoid that with the correct solution, I don't see any issue.  After all, nothing prevents you from moving the splitter all the way to the right and losing the attachments inthe compose window.

Comment 91

[David :Bienvenu]

I agree with Bill - also, if you've managed to hide the attachment box, when you select an other message and back, the attachment box will re-appear, right?

Comment 92

[Wayne Woods]

Attachment: Version 2 patch for trunk

Well, the flex thing turned out to be a dead-end (though educational). It worked, but really no better than the other method (the box still didn't resize much when it'd be useful for it to), and it required more calculations. So I went back to the original method and updated the patch.

Please test the current patch on Windows or Linux and tell me how it looks. Especially the following:
- if the splitter merges seamlessly with the attachment box margin now (I'm hoping I've got it right this time)
- if any margins are too small or too large
- if the "Attachments" label lines up with the first line of files. On Mac, I've adjusted it so the label text is at exactly the same height as the filename text. If it needs further aligning, please tell me by how many px

As per mcow's suggestions, I've changed the attachmentList styling for Qute. I also changed the margins for Pinstripe a bit.

I didn't add a min-height setting. As I mentioned previously, it didn't do anything useful. At least removing the grippy will stop people accidentally collapsing the box instantly. If they shrink it using the splitter and still can't work out where the box went, there's really not much hope for them.

I don't have a decent work-around for the "empty" scrollbar at small box heights, and it's something we may just have to put up with. The problem is that if I style to increase the min box height when it overflows (so that the box is now tall enough to have a proper scrollbar) then there's a chance it'll also now be tall enough to no longer be overflowed. So then it tries to shrink again... causing a loop. Maybe I'll find a workaround in time, maybe not. But I'm not going to delay the patch for it.

Anyway, please let me know what you think!

Comment 93

[Mike Cowperthwaite]

Attachment: Screenshot: many attachments, with scrollbar (Win2K vanilla, qute)

Comment 94

[Mike Cowperthwaite]

Attachment: Attachment bar with only a couple attachments

Comment 95

[Mike Cowperthwaite]

Attachment: Attachment bar, collapsed

These three shots show the appearance.  I don't think you've achieved the "seamless" edge between panel and splitter.  I wonder if that border is part of the splitter?  In the previous patch, I didn't notice the top border of the attachment panel anyway -- I don't see a visible difference here from the last one.

One thing I notice (which was the case with the previous patch): when the panel is scrolling, it's the entire panel.  The <description> element is as tall as it needs to be for all the items, and if that's too tall for the panel, it's cut off -- you don't see the bottom border of the <description>.  I think we've already established that the <description> element doesn't do a good job of handling overflow:scroll itself, so this is unavoidable.  You could even say it's a benefit -- in the case where the scrollbar disappears due to insufficient height of the panel, the missing border is a (subtle) cue that there is more to be seen than is visible.

btw, for people who want the grippy, there is an extension:
  https://addons.mozilla.org/thunderbird/2242/
It's only compatible thru 1.5, but I'll bet the author would make sure that the grippy appears on this splitter.

Comment 96

[Wayne Woods]

Attachment: Version 3 patch for trunk

Thanks Mike. Try this one. Hopefully I got it right this time. I also adjusted the Attachments label down 5 px to line up with the first row of attachments.

Comment 97

[Wayne Woods]

Attachment: Version 3 patch with no-scroll attachments label

If you want to see what it looks like when the "Attachments" label doesn't scroll, try this experimental patch out. I got the attachments list to scroll by enclosing it in a hbox.

With this version, I notice that I'm getting "empty" scrollbars more often, but that might just require some experimenting... I only just knocked it together and haven't had a chance to tinker further.

Comment 98

[Scott MacGregor]

mcow, have you tried out Wayne's attachment 253895 [details] [diff] [review] for the trunk? just curious if you had any more UI feedback before I dig in on the review.

Comment 99

[Mike Cowperthwaite]

Attachment: Screenshot: qute/Win2K, boundary between attachment and 3pane's messagepane

That version does eliminate the bottom border of the splitter so that it's a smooth merge.  I'm not sure why there's a an additional border around the message body in the standalone window, compared to the 3pane.  In the 3pane, the border between splitter and message body is nearly invisible, at least with my color scheme, as seen in this screenshot.  That's specified with this:
=================
#attachment-splitter {
  height: 5px;
  border-top: 2px solid ThreeDShadow;   /* <-- this one */
  border-bottom: none;
}
==============
With 2px, the border is visible; 3px might be a little better, but it's hard to tell for sure.  Also, instead of "solid ThreeDShadow" I think "outset" gets the same style; the color that actually gets used, it seems to me, is ThreeDHighlight, I'm not sure why.  The desired appearance, I think, is outset.  However, again, the extra (solid 1px) border in the standalone window changes the appearance slightly.

Comment 100

[Wayne Woods]

(In reply to comment #99)
> Created an attachment (id=254597) [details]
> With 2px, the border is visible; 3px might be a little better, but it's hard to
> tell for sure.  Also, instead of "solid ThreeDShadow" I think "outset" gets the
> same style; the color that actually gets used, it seems to me, is
> ThreeDHighlight, I'm not sure why.  The desired appearance, I think, is outset.

Thanks Mike. The missing (or thin?) border above the splitter is quite obvious, so we'll definitely need to get that right. And I'm not sure why the message window is displaying differently. Are you able to use userChrome.css to explore these more easily?

One other thing... do you prefer the version where the label doesn't scroll with the attachments? If so, I'll post a better version. I'm leaning towards using flex again, now. I originally thought there were problems with it that were making the "ghost" scrollbar appear more often, but it turns out that was an unrelated Mac trunk bug which is now fixed (bug 369610).

Comment 101

[Mike Cowperthwaite]

Attachment: Screenshot with tweaked border

Here's a shot of the 3pane (left) and standalone (right) where I've tweaked the splitter border as:
  border-top: 3px outset;
You can see the extra line of border for the standalone here.

> And I'm not sure why the message window is displaying differently. Are you
> able to use userChrome.css to explore these more easily?

I just looked at the two in side-by-side DOM Inspector windows and I can't see an obvious reason for the difference.


As for the non-scrolling label: I do think that's an improvement.

Comment 102

[Wayne Woods]

Attachment: Version 4 patch - minor css changes and uses flex again

Comment 103

[Wayne Woods]

(In reply to comment #101)
>   border-top: 3px outset;

The latest patch has that fix.

> You can see the extra line of border for the standalone here.

I still don't know where this border is coming from. One thing I did notice in the Pinstripe version is that some css in toolkit/themes/pinstripe/global/splitter.css seems to define the splitter that is used in Mac Thunderbird. If this is true, maybe maybe the Winstripe equivalent file is affecting the Qute theme?
http://lxr.mozilla.org/seamonkey/source/toolkit/themes/winstripe/global/splitter.css
If so, maybe the background or background-color needs to be overridden.

My only other thought is that maybe it's the messagepane border-bottom, and not the splitter at all. But if that's being defined somewhere, I can't see where.

Unrelated thought I'll investigate (but please don't let it hold up review): since the attachments box is usually so small, try out the small scrollbars and see how they look/behave. If I can work out how to set them...

Comment 104

[Mike Cowperthwaite]

(In reply to comment #103)
> My only other thought is that maybe it's the messagepane border-bottom, and
> not the splitter at all. 

Oof -- I thought that was clear, but I guess it wasn't.  Yes, this definitely is a border of the message pane, not the splitter -- there's a similar extra pixel of border seen at the top of the message pane as well.  I was only mentioning it because it affects the appearance of the outset border on the splitter.  Sorry for the confusion.

Comment 105

[Bill Gianopoulos [:WG9s]]

If we are going to be quibbling abut an extra pixel here or there, then we really need to be testing on the branch and not the trunk.  The trunk has rounding fixes, the new units code and the reflow branch landing, which all have cases that make things work differently by a pixel or so.  Trying to get things to look pixel perfect on the branch by testing on the trunk at this point is, in my opinion, pointless.

Comment 106

[Mike Cowperthwaite]

Well, I have been testing on the branch, for one thing; and I'm not quibbling over "an extra pixel or two," I'm pointing out the existence of what seems to be a additional, unexpected border in the standalone window.  The 'outset' border style, in particular, is used to get a particular appearance that's 
well-integrated into the skin; and that border looks slightly different, slightly wrong, if there's an extra intervening line.

Comment 107

[Bill Gianopoulos [:WG9s]]

(In reply to comment #106)
> Well, I have been testing on the branch, for one thing;
> 
OK I had assumed from Wayne's earlier comment that he was only producing a trunk patch until the patch was right that no one was testing on branch.

I probably should not have used the work quibble.  My only point was that if we have not given up hope on getting this into 2.0 we needed feedback on what it looks like in branch.  I guess I was just confused and did not realize that is what you were giving.  I am in the process of doing a branch build myself with this to do some testing as well.

Comment 108

[Bill Gianopoulos [:WG9s]]

Attachment: Message window magnified screenshot

OK I think I see what you mean.  In the Message Window there is not really an extra line, but a gap between the line above the attachments pane and the pane itself which shows up as a white stripe which should not be there.  Is this what you were referring too, or are you seeing something different?

Comment 109

[Bill Gianopoulos [:WG9s]]

Attachment: Patch I applied to the branch

The trunk patch does not apply cleanly on the branch.  I am attaching the patch as I applied it to the branch merely for reference and so others can point out if I screwed up in merging it.  I also thought it would be nice if there were some way to determine if everyone testing on branch were testing the same thing.  This does not mean I am taking this bug.

Comment 110

[Bill Gianopoulos [:WG9s]]

Attachment: Patch I really applied to branch

Oops did the diff against HEAD instead of the branch.

Comment 111

[Bill Gianopoulos [:WG9s]]

Attachment: Corrected branch patch

Noticed the code for pinstripe didn't merge correctly.  I think this is now a correct branch patch.  The screenshots, were created under Windows/XP using qute, so they are still valid.

Comment 112

[Wayne Woods]

Thanks Bill. The Pinstripe css for the branch will need a bit more tweaking, I think, but I can take care of that.

As for the mystery border... man, this is frustrating. I really need to get an Intel Mac so I can dual boot and test build this stuff myself ;)

Judging from the standard 1.8 nightly Windows builds, that dark line above the attachment box really has to be the top border of attachmentView. It only appears in the message window, not 3pane, and if I add:
#attachmentView { border-top: none !important; }
to userChrome.css, it goes away.

Of course it doesn't make sense that it's that border, given that we're explicitly turning it off in the css. But as far as I can tell, it has to be.

A couple of things to try:
1. Try adding a !important after the "border-top : none". Maybe there's a problem of precedence somewhere.
2. In messageHeader.css for Qute, try adding "border-top : none;" to .headerContainer

Comment 113

[Bill Gianopoulos [:WG9s]]

(In reply to comment #112)
> appears in the message window, not 3pane, and if I add:
> #attachmentView { border-top: none !important; }
> to userChrome.css, it goes away.

That does not make it go away for me.
 
> Of course it doesn't make sense that it's that border, given that we're
> explicitly turning it off in the css. But as far as I can tell, it has to be.
> 
> A couple of things to try:
> 1. Try adding a !important after the "border-top : none". Maybe there's a
> problem of precedence somewhere.
> 2. In messageHeader.css for Qute, try adding "border-top : none;" to
> .headerContainer
> 

Neither of those helps.

However adding this to userChrome.css makes it vanish:

#attachment-splitter { border: none !important; }

Comment 114

[Bill Gianopoulos [:WG9s]]

Hmm the following is in the patch for qute but not the patch for pinstripe.  Should it just be removed?

#attachment-splitter {
  height: 5px;
  border-top: 3px outset;
  border-bottom: none;
}

Comment 115

[Bill Gianopoulos [:WG9s]]

Changing the #attachment-splitter border-top from "3px outset" to "1px solid" makes it look like the current branch builds.

Comment 116

[Bill Gianopoulos [:WG9s]]

Actually, the order removed from the top of the attachment panel was:

 1px solid ThreeDShadow;

So, that is probably what should be the top border on the splitter in lpace of the 3px outset, which does not work.

Comment 117

[Wayne Woods]

I think I see the problem now. As I mentioned in comment 103, I think the splitters for the message window are getting styles from an external sheet (link in that comment), while the splitters in the 3pane aren't. Why it's the case, I don't know, but that seems to be the case for Pinstripe and presumably Qute. If so, the splitter is getting the style:
-moz-border-top-colors: ThreeDShadow ThreeDHighlight;

This sets up a striping effect.  See http://zenit.senecac.on.ca/wiki/index.php/CSS_GUIDE_-MOZ-BORDER-TOP-COLORS for a reference.

But I think combined with a 3px border and also the outset style declaration without any colour declaration, it becomes ugly. If the colour is set during the style definition, as it was originally (and as you described in your last comment) this overrides it.

So, anyway, the colour really needs to be defined along with the outset/solid style. Whether ThreeDShadow or ThreeDHighlight (and also whether solid our outset) is up to you guys...

Comment 118

[Bill Gianopoulos [:WG9s]]

Silly me!  I had one of the workarounds form an earlier comment in this bug in my userChrome.css file so that I had non-default styles on the messagepane.  I now have the following in messageHeader.css for qute.  I added the top border on the atachmentsView back as this now makes it look more like there is a movable splitter.  All looks well with no userChrome.css file to me.  If you want it too look like it used to then set the top-border on attachmentView to none, but that kind makes it impossible to tell there is a splitter there unless you mouseover it.

What I now have for style rules is as follows:

#attachmentView
{
  border-top: 1px solid ThreeDShadow;
  border-bottom: none;
  background-color: -moz-Dialog;
}

#attachmentContainer[attachmentOverflow="true"] {
  overflow: auto;
}

#attachment-splitter {
  height: 5px;
  border-top: 1px solid ThreeDShadow;
  border-bottom: none;
}

Comment 119

[Mike Cowperthwaite]

Attachment: Screenshot with CSS from comment 118

> I added the top border on the atachmentsView back as this now makes it look
> more like there is a movable splitter.  [...] If you want it too look like it
> used to then set the top-border on attachmentView to none, but that kind
> makes it impossible to tell there is a splitter there unless you mouseover it.

That's true; I thought that was Wayne intended by a "seamless merge."  But the other splitters in the UI (search messages window, compose window) show explicit borders.


> All looks well with no userChrome.css file to me.

Really?  In a 3pane window, the border between splitter and message body is barely visible; in a standalone window, there is an extra border.  I'm still not sure where it comes from.

I'm not wed to using 'outset' for the splitter's top border; if you look at a short (no scrollbars) message with no attachments in the 3-pane, the right and bottom borders don't have that subtle 3-D effect; the left border does, just because that border is a splitter.  The top border is a simple black line.

So, a simple solid border on the splitter would be fine, just as seen at the bottom of the headers panel.  The problem is, I can't figure out a way to set that color -- even if I use
  #attachment-splitter { border-top: 4px solid red; }
I'm not seeing a border of that width in any color; I'm only seeing an additional 1px border of what appears to be "3DHighlight" -- the same results seen with
  #attachment-splitter { border-top: solid; }
So somewhere, something is overriding the width and color, but that's not part of the CSS rules, as seen in DOM Inspector.  Only if 'solid' is replaced by 'outset' (or, maybe, another style?) do I get any control over the width, in which case the colors are not under control.

Here's what I think works best: 
 - remove *all* the styling on #attachment-splitter, as the default gives a 5px with 1px light border on top and 1px dark border below; and 
 - restore the 'border-top:none' to #attachmentView.  
This shows the splitter that appears like the other splitters in the theme; and if someone wants to customize splitter styling, they don't have to do anything special for this one.

Comment 120

[Bill Gianopoulos [:WG9s]]

Actually that was what I was going to try next.  I suspected the default slitter might look OK.  The main reason I wanted to leave the top border on the attachment pane is that if people really objected to the visible splitter they could easily do a display:none on it in  userChrome.css and get back the same look as current trunk builds.

I found that all the oddities I was seeing in the 3 pane view were due to a userChrome.css rule I had that was trying to enforce a minimum height on the messagepane as a workaround for thee attachments taking over the entire message area.  I suppose you already ave, but it would not hurt to check your userChrome.css to make sure you have no such rule. 

Comment 121

[Wayne Woods]

Yeah, I intended the splitter to merge with the attachments box. But that might look better in Pinstripe than Qute, given that the existence of a splitter is not obvious in the latter. If you add the border back, the splitter borders and colour should probably make it merge with the other 3pane splitters and so look "raised" compared to the attachmentView.

As for the continuing saga of the mystery border, rather than spamming this list with more suggestions... does anyone have a Windows build that I could download from somewhere and try out on my work machine? I just can't build, but I can still test. If so, please email me.

Comment 122

[Bill Gianopoulos [:WG9s]]

I ended up going back to the style rules from comment #18 as that makes the splitter look like other splitter in the application.

As for the phantom border, I figured that out as well.  It was not an extra line in the standalone window.  It was the top border of the splitter which was incorrectly styled.  The reason it did not show up in the 3 pane view, is that depending on screen resolution, the top couple of rows of pixels of the attachment panel appear not to display.  I am missing the border on the attachment panel in the 3 panel view when I have my laptop undocked.  I have a widescreen monitor on the laptop so have the screen set to 1280X800.  I have a normal aspect screen when docked so the resolution is 1280X1024 and the border draws the same in both views when docked.  It is only when undocked with the 1280X800 screen resolution that the top border on the splitter is absent in the 3 pane view.  I would not worry about this at all. The top border on the attachment panel is missing in the view on the latest branch nightly at 1280X800 resolution as well,nightly so this has nothing at all to do with your patch.

Comment 123

[Wayne Woods]

God, you're right. It's a size/drawing issue that is probably not our fault at all. I can see that if I have the 3pane at full-screen size, the attachmentView border sometimes appears, but if I switch to a floating window, it immediately vanishes.

I have some other issues to tidy up and I'll post a new patch tonight.

Comment 124

[Bill Gianopoulos [:WG9s]]

(In reply to comment #122)
> I ended up going back to the style rules from comment #18 as that makes the
Ahh, I meant comment #118.

Comment 125

[Wayne Woods]

Attachment: Version 5 patch - trunk

Minimal styling, as per Mike's suggestions in comment 119. If nobody has any problems with this one, I'll mark it for review. We can tweak style in another patch later, so only worry about style issues that are actual bugs. I just wanna get this in.

I didn't have time to produce a branch version today. If nobody has any problems with this version, I'll post the branch patch in a day's time, unless someone else volunteers first.

Of note, the method doesn't use flex. With this patch, I was able to remove any visual artefacts that I could see, and with minimal code. The flex version was much bulkier and still resulted in a border vanishing some of the time.

Comment 126

[Scott MacGregor]

Comment on attachment 255004 [details] [diff] [review]
Version 5 patch - trunk

Thanks! I think you meant to mark this as ready for review from me.

I'll get to this within the next 24 hours.

Comment 127

[Wayne Woods]

(In reply to comment #126)
> Thanks! I think you meant to mark this as ready for review from me.
> I'll get to this within the next 24 hours. 

Thanks. Actually, I deliberately didn't mark it for review till I was sure there were no comments. I thought you'd be sick of seeing it cancelled with each new patch.

Comment 128

[Scott MacGregor]

Attachment: screen shot of a twist...

I've been experimenting with Wayne's excellent version 5 patch today and tweaked it a little bit to come up with this screen shot. I like this large icon view a lot more, it looks cleaner, I felt the attachment label was always extraneous anyway. This layout is very similar to what we used to do in Netscape 4. 

Thoughts? If we went with this screen shot, maybe we can tweak the cropping on the attachment names so they aren't quite so wide.

Comment 129

[Scott MacGregor]

Attachment: same idea but with small icons

and power users looking to maximize real estate can set a pref to use small icons in the attachment box like this screen shot shows.

Comment 130

[Paul Ellis]

Personally, I like the small icons better.  But for the average user the large icons are probably better.  I think the large icon layout might look better as a tile view (icon to the left of the filename).  Much like XP's tile view actually. 

Comment 131

[Magnus Melin [:mkmelin]]

I also like the version with small icons, not too fond of the one with larger ones. Just my 5c.

Comment 132

[Scott MacGregor]

Attachment: large icons with the text to the right

For more comparison, put the text to the right of the large attachment icon like Windows XP does.Would be really sweet if we could show the content type and attachment size underneath the file name but I'm getting ahead of myself now.

Comment 133

[Paul Ellis]

That is exactly what I was thinking, really along the XP way of doing things.  I don't know how hard it is to add content type, especially on on multiple platforms, but would file size be easier to add?  How will really long file names be handled under this layout?

Comment 134

[jwq]

 I appreciate all the work everyone, Wayne in particular, has performed for this bug. I have to say, though, that I'm not so keen on a Windows-XP-style, it rather clashes with my Mac OS X decor ;-)

 I'd like to see a list view in the attachments pane, analogous to the message list pane. As space permits, the list could extend to n columns. Ideally, the list would contain a configurable set of subcolumns (filename, size, content-type, etc.) whose widths could be changed. The similarity of such an attachment list to the message list makes this layout intuitive.

Comment 135

[Wayne Woods]

I think it looks good, Scott. If I'd thought you'd be happy with the Attachments label gone, it would have saved me hours of headaches ;)

I prefer the large icon view. Aesthetically, I also prefer the label underneath the icon, though I'm not committed to that: I know that isn't the most efficient for scanning large numbers of files, but it should be the most efficient for space, with multiple rows. Label underneath is also the way that Apple's Mail app presents attachment files, though unless it's in the Apple HIG, there's no reason we have to copy the way that Mail does it on Mac (any more than copying a list view style because Outlook Express does it, I suppose ;) )

Anyway, let's just get something in, and open another bug to improve the style of the thing for future versions.

Comment 136

[Greta]

It's great to see work being done on this bug!  I had been holding off switching to Firefox/Thunderbird due to this bug.  My preference would be no icons, so one can see as many of the attachment names as possible in the pane.

Comment 137

[Scott MacGregor]

(In reply to comment #135)
> I think it looks good, Scott. If I'd thought you'd be happy with the
> Attachments label gone, it would have saved me hours of headaches ;)

heh. Sorry about that, I wouldn't have thought to remove it until I had a chance to see your great work in action.
> 
> I prefer the large icon view. 

I'm going to move ahead with the large icon view, since you've put so much work into this bug.

> Aesthetically, I also prefer the label underneath
> the icon, though I'm not committed to that: 

I'm going to try that for now. We can always change the behavior between platforms.
 
> Anyway, let's just get something in, and open another bug to improve the style
> of the thing for future versions.

Agreed! Any of these options are so much better than what we've got. I'll drive it into the tree tonight, it may not be perfect but we can tweak it together once the patch is in.

Comment 138

[Scott MacGregor]

Attachment: updated fix with large icons

Wayne, if you are still up (not sure what time it is in Australia), did you want to take a quick glance through the patch one last time? 

This takes the great work you did, ditches the Attachment text, uses large icons with the icon above the text and uses a min height of 55 pixels.

Comment 139

[Wayne Woods]

Attachment: mac Screenshot with version 6

Functionally, it looks good. But you stripped out all the attachmentView styling for Mac, and it now looks like a very plain white box (see screenshot). Sorry, I don't have time to produce an update to the patch this afternoon, but if you put back the rest of the styling, I think it'll look fine. I tested it out by adding the following in userChrome.css and it looked OK again:
#attachmentView {
  background-color: #E6E6E6 !important;
  border: 1px solid #C8C8C8 !important;
  -moz-border-radius: 7px !important;
  margin: 0px 6px 6px 6px !important;
  padding: 4px !important;
}

Cheers

Comment 140

[Scott MacGregor]

Wayne, I don't have access to a Mac here at home, what does it look like after you added back the attachmentView styling?

Comment 141

[Scott MacGregor]

Attachment: updated fix with Wayne's comments

added back the mac style rules per Wayne. Carring forward my sr for his patch.

Comment 142

[Wayne Woods]

Attachment: Screenshot with Pinstripe attachmentView styling restored

That's what it looks like with the styling back. Compare to attachment 255526 [details]. The grey background breaks up the starkness.

Comment 143

[Wayne Woods]

Attachment: Screenshot of Pinstripe with older version (version 5)

For comparison, here's what it looked like with the version 5 patch on Mac.

Comment 144

[Wayne Woods]

The latest patch looks good. Thanks Scott. Anything else can wait for a spin-off bug :)

Comment 145

[Scott MacGregor]

Ok, this is checked into the branch and trunk. I've filed Bug 370792 to track styling improvements and suggestions so folks can add comments there. Thanks so much Wayne! You are my hero! :)

Comment 146

[hansen]

It has been an awesome trip to follow this bug - thanks!

Just a tiny question; what will happen to this config, if we're going for the large icons by default?

mailnews.attachments.display.largeView

Comment 147

[sam tygier]

sorry for noise, but which release will this make into? will it be in thunderbird 2?

thanks

Comment 148

[Tuukka Tolvanen (sp3000)]

> sorry for noise, but which release will this make into? will it be in
> thunderbird 2?

Yes (fixed1.8.1.x in keywords; 1.8.1 branch == fx/tb 2.0)

Comment 149

[Bill Gianopoulos [:WG9s]]

(In reply to comment #146)
> It has been an awesome trip to follow this bug - thanks!
> 
> Just a tiny question; what will happen to this config, if we're going for the
> large icons by default?
> 
> mailnews.attachments.display.largeView
> 
The preference is still there and active.  The patch merely alters the default value from false to true.  You can set it to false to go back to small icons with the filename to the side.

Also, the code that alters the default to the large icons appears to have been checked into the trunk only, so the branch behavior has not changed.

Comment 151

[Mike Cowperthwaite]

Verified Fixed with TB 2b2-0219, Win2K.  Thanks again, Wayne.

Note that changing the 'largeView' preference requires a restart to take effect.

Comment 155

[Samuel Sidler (old account; do not CC)]

Verified fixed on the 1.8 branch using Mac OS X and version 2.0.0.0pre (20070328). This was also verified per comment 151.

Comment 157

[Kent Tong]

I have a mail with 5 attachments but only 3 are shown. There is no scroll bar
displayed. Even if I resize the attachment pane to make it tall enough to 
accommodate the attachments, only the first row is shown. The rest is just
a gray area.

Please see the attached screen shot for what I mean.

Comment 158

[Kent Tong]

Attachment: no scroll bar. Just a grey area. Only one row is shown.

I am using thunderbird 2.0.0.6 on Windows 2000.

Comment 159

[Wayne Woods]

Hi Kent, if this is a recent regression, you should probably open a new bug on this (and please add me to the cc list). Before you do, however, please check that you're not using any third-party themes or any other add-ons that might affect the attachments bar, and also you don't have anything related to the attachments bar in your userChrome.css file (if you've ever used that).

Comment 160

[Kent Tong]

Right! I was taking the advice from 
http://ilias.ca/blog/2005/10/limiting-the-attachment-window-size-in-thunderbird/ 
and added:

   #attachmentList {max-height: 4em !important;}

to the userChrome.css file. After removing this line it works fine. Thanks!

Comment 161

[Wayne Woods]

Yeah, that predates this fix. Glad that's all it was :)