1738575 - Showing another address row after using splitter causes unwanted overflow (explore removing grippy between ComposeHeaderArea and ComposeEditor)

Status: RESOLVED DUPLICATE of bug 1720348

(Thunderbird :: Message Compose Window, enhancement)

Description

[John Bieling (:TbSync)]

I see complains in support, that the address input fields sometimes are partially hidden but after looking at the code I saw that this is currently by design to honor the user-defined height of the ComposeHeaderArea, when the grippy has been used to manually set a height.

STR:

• open a compose window
• grab the grippy and move it down a bit to increase the ComposeHeaderArea
• grap the grippy again and move it back up to where it was before
• click on the CC or BCC field to enable them
  -> fields go into overflow

Can we remove that altogether and just have those fields stack normally, automatically correctly adjusting the height of the header area? We could then get rid of the calculateHeaderHeight() and friends.

Is there a special reason to allow this height adjustment? Is vertical screen space still an issue? With the new pill system we only have a maximum of 6 fields and if they contain a lot of recipients, the fields may wrap over multiple lines, but on current screen sizes, this does not seem to be an issue anymore.

Comment 1

[Alessandro Castellani [:aleca]]

The height calculation of the compose header is still needed for those users that have a small screen
For cases when adding a lot of recipients on multiple recipient fields, the header should be prevented from growing past 3/4 of the full window height in order to prevent covering the message body, and making it impossible to resize.

That method is not very well done and it creates various issues, one of which you reported here.
We already have bug 1720348 which should take care of some of the issues, but this one might not be covered.

Thanks for the detailed report.

Comment 2

[Thomas D. (:thomas8)]

(In reply to John Bieling (:TbSync) from comment #0)

I see complains in support, that the address input fields sometimes are partially hidden but after looking at the code I saw that this is currently by design to honor the user-defined height of the ComposeHeaderArea, when the grippy has been used to manually set a height.

STR:

• open a compose window
• grab the grippy and move it down a bit to increase the ComposeHeaderArea

Why would you want to increase an empty AddressingArea??
It's a bug that creating a useless gap between subject and recipients via drag down is possible in the first place, and it's now covered in Bug 1720348 Comment 5.

• grap the grippy again and move it back up to where it was before

This is an artifact from the bug described above, so after fixing that, it will no longer be a real-life scenario.

• click on the CC or BCC field to enable them
  -> fields go into overflow

That's a bit odd, I've proposed to expand to default height for that case in Bug 1720348.

Can we remove that altogether and just have those fields stack normally, automatically correctly adjusting the height of the header area? We could then get rid of the calculateHeaderHeight() and friends.

Is there a special reason to allow this height adjustment? Is vertical screen space still an issue? With the new pill system we only have a maximum of 6 fields and if they contain a lot of recipients, the fields may wrap over multiple lines, but on current screen sizes, this does not seem to be an issue anymore.

As Alex pointed out, vertical screen space is definitely still an issue.

• Lots of recipients (50+, 100+);
• recipients with display name and longer email addresses (meaning less recipients will fit in each row)
• TB in half-screen size: On my 27 inch, that allows just two full recipients like Thomas Düllmann <[e-mail]> for each row, so if you have something like 50 recipients, that's 25 rows. Composition window half-screen size is extremely useful for a number of scenarios like dragging attachments in, viewing/copying relevant information while composing etc.
• small monitors (Laptop)

I don't think we can remove the splitter/grippy without a redesign of the entire area; and even then, it may still be needed. For details, see my Bug 1720348 Comment 5.

I suggest to close this as a duplicate of bug 1720348 for now.
Exploring a redesign which auto-collapses addressing area when it's not in use should probably get a clean new bug focused on that.

Comment 3

[Thomas D. (:thomas8)]

Adjusting summary to cover the usability bug described (which is covered in bug 1720348).
Removing overflow behaviour of recipients fields completely isn't possible as Alex explained.

Comment 4

[Thomas D. (:thomas8)]

I have talked about this with John and we have agreed to resolve this as a duplicate of 1720348.