760079 - Attachment box should be wider

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement)

Description

[Vincent (caméléon)]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Build ID: 20111120135848

Steps to reproduce:

from http://gsfn.us/t/2w3e0

When I add an attachment to an email a very small window appears in the top right hand side of the email. How can I make this window wider, not longer as I don't add many attachments just the attachment names are long


Actual results:

The attachment filename is very often truncated


Expected results:

The attachment box should be taller, or auto adapt to the attachment's filename.
We give too many space for email address, and not enough for the attachment's name.

Comment 1

[:aceman]

For me on Win XP, the attachment box is resizable (drag the egde between the attachment box and the email addresses). Does it not work for the reporter?

Comment 2

[Vincent (caméléon)]

Yes it works, but it is only a workaround, not a good fix for the issue.

Comment 3

[:aceman]

So you want the attachment box to be permanently wider?
I'd suggest it just keeps the size permanently once you resize it. Which is not the case now, at each opening of the compose window the size is reset back.

Comment 4

[Vincent (caméléon)]

Attachment: screenshot of the issue

hope that it is clearer with this screen-shoot. There is only the place for 11 characters for the file-name, it is really not sufficient!

Comment 5

[Jim Porter (:squib)]

Attachment: Persist the attachment width

(In reply to :aceman from comment #3)
> I'd suggest it just keeps the size permanently once you resize it. Which is
> not the case now, at each opening of the compose window the size is reset
> back.

This seems reasonable. Here's a patch.

bwinton, one note on the patch: I added a min-width to the attachmentBucket so that it won't shrink to 0px before collapsing. This way, when you open a new compose window after dragging the attachment bucket to collapse it, it'll still open with a sane width. 10em seems like the smallest reasonable value for this, though perhaps we could go a bit larger.

Comment 6

[:aceman]

Cool. I almost had a patch for this:) I had the persist="width" parameter but it didn't work by itself. I didn't notice the resetting "document.getElementById("attachments-box").removeAttribute("width");" .

Maybe Seamonkey would want this too.

Wayne, can you take care (post status updates) of the GS topic?

Comment 7

[Vincent (caméléon)]

any reason why we don't also change the default value? I don't understand why we need so much space for the address's box (which usually only contain one address per line) and so few for the attachment's box.

Comment 8

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 629087 [details] [diff] [review]
Persist the attachment width

I would go much larger.  Twice as large doesn't seem unreasonable to me.

Actually, what I _really_ want it to do is remember the width it was at when I pressed the mouse button before collapsing, and return to that, instead of returning to the minimum width.  :(

I guess this is good for what it does, though, so ui-r=me, with a plea to implement the cooler behaviour I describe above.  ;)

And the code seems fine, so r=me, too.

Thanks,
Blake.

Comment 9

[Jim Porter (:squib)]

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #8)
> Comment on attachment 629087 [details] [diff] [review]
> Persist the attachment width
> 
> I would go much larger.  Twice as large doesn't seem unreasonable to me.

How about 15em then? That's how big the attachment bucket is currently.

> Actually, what I _really_ want it to do is remember the width it was at when
> I pressed the mouse button before collapsing, and return to that, instead of
> returning to the minimum width.  :(

That probably necessitates a change in the <splitter> code, since we'd want that elsewhere too (e.g. the 3pane). I'll file a followup bug about this.

Comment 10

[Blake Winton (:bwinton) (:☕️)]

Sure, 15em sounds fine.

Thanks,
Blake.

Comment 11

[Jim Porter (:squib)]

Checked in: http://hg.mozilla.org/comm-central/rev/f060e51439c5