473534 - Resize mail compose headers-box

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[[:Aureliano Buendía]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1b3pre) Gecko/20081204 Lightning/1.0pre Thunderbird/3.0b1 ID:20081204115318

Resize headers-box to decrease height, produce a wrong views.
See attached file to details.

Reproducible: Always



Expected Results:  
Header-box should be a minimun height that show both msgHeadersToolbar and formatToolbar.

Comment 1

[[:Aureliano Buendía]]

Attachment: details

Comment 2

[Jan Horak [:jhorak]]

It is OK in latest Thunderbird (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090115 Shredder/3.0b2pre).

Comment 3

[Jan Horak [:jhorak]]

Attachment: Fix for theme

I'm sorry, I was wrong. This issue is present in current tree. I'm sending fix for GTK. Windows theme is also fixed by the same way as GTK but it needs to be tested yet.

Comment 4

[Mark Banner (:standard8)]

Comment on attachment 360304 [details] [diff] [review]
Fix for theme

rcampbell isn't a mail/ reviewer. Switching review.

See http://www.mozilla.org/mailnews/review-mail.html for the current review list.

Comment 5

[[:Aureliano Buendía]]

This bug should be markes as "NEW" and not as "UNCONFIRMED".

Comment 6

[Phil Ringnalda (:philor)]

Comment on attachment 360304 [details] [diff] [review]
Fix for theme

Definitely not for the Windows/qute part: not surprisingly, qute was better adjusted for Windows than Linux, so that takes it from "not much of a problem" to "um, now we have 4 and a half rows of addresses."

Comment 7

[Phil Ringnalda (:philor)]

But, I don't think that's the right place to be fixing either one: the problem is not that you can make the whole top half of the window less than a fixed number of pixels, it's that you can run the format toolbar (or the splitter, for plain text compose) over the top of the box with the subject in it. Even with your patch, try setting a larger application font size and you'll see that you're right back to running up over the subject, so I suspect the right fix is to give the subject box a min-height that's relative to the font size.

Comment 8

[Jan Horak [:jhorak]]

Attachment: Patch for setting min-height of toolbar in runtime.

Thanks for your suggestions. Unfortunately setting min-height does not have any impact in this issue. The only method which appears to be working for me is setting min-height of whole toolbar. You're right that adjusting static values does not help. I've created a patch which set min-height of toolbar to its actual height at window creation. Thanks for any further advices.

Comment 9

[Joshua Gourneau]

I think I am having a similar problem on OS X. 

See the video at:
http://www.screencast.com/users/JoshuaG/folders/Jing/media/47557cd4-23e6-4edd-b8b9-8b7ce97a9626

Is this worthy of a new ticket?

Comment 10

[Phil Ringnalda (:philor)]

Attachment: For checkin

Thanks for the patch!

I'll push this slightly modified version in a bit. The difference is just style: we generally only put bug numbers in a comment when it's "see this still open bug about doing something else and getting rid of this code," and (mostly) use interCaps instead of underscore_separated variable names in JS, and that GetMsgHeadersToolbarElement() function is the worst sort of global scope pollution, providing a global var that can't be used since you don't know if it's been initialized, so you have to call a global function that just does getElementById(): we shouldn't encourage it to exist by giving it it's first and only caller.

Comment 11

[Phil Ringnalda (:philor)]

Joshua: no, not worthy of a new ticket, since that's exactly this bug.

Comment 12

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/comm-central/rev/17e7a33d3a57