I am looking at the latest available iteration of bug 440377 (try build 73.0a1 (2019-12-06) (64-bit).*

STR

1. new msg with to, cc, and bcc recipients
2. optionally open attachment pane
3. drag splitter below formatting bar all the way to the top (to vertically minimize recipient area)

Actual result

• UI chaos as formatting toolbar visually overlays sender field and attachment pane

Expected result

• keep UI intact
• some way of intelligently collapsing of CC and BCC etc. fields

Proposed minimal solution

• add vertical min-height for recipient area
• when recipient fields like To, CC, or BCC fields are out of view, collapse them similar to the current CC/BCC buttons, and indicate the number of hidden recipients:

From:     The sender <sender@foo.bar>
          ⊕To (5 🙂🙂)     ⊕CC (3 🙂🙂)      ⊕BCC (1 🙂)
Subject:  Recipient area minimized

          ⊕An (5 🙂🙂)     ⊕Kopie (CC) (3 🙂🙂)      ⊕Blindkopie (BCC) (1 🙂)

The collapsed representation of "n recipients" should probably be iconic because in other localizations like German, a short caption like BCC ends up as Blindkopie(BCC), so if we add the word "recipients" all over, things may get lengthy. We could use the actual smiley character as above (without the yellow), or something like the contact / mail list icons respectively.

We also need a horizontal max-width for recipient area, typing a very long email recipient address into a single pill will push attachment pane out of screen and even make recipient area truncated on the right.

*: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9

Note: comment 0 edited for better "visual" representation of the minimal solution.

In the long run, I believe we also want a solution to collapse the entire recipient area to a single line, or to the side (on top of contacts side bar), or even to iconic state, maybe on the formatting toolbar (something similar for plaintext compositions). It's one of the painpoints of TB that this area gobbles up a LOT of screen space.

We also need a horizontal max-width, typing a very long email recipient address into a single pill will push attachment pane out of screen and even make recipient area truncated on the right.

(In reply to Thomas D. from comment #0)

Actual result

• UI chaos as formatting toolbar visually overlays sender field and attachment pane

Alex, Richard, could this be avoided with a min-height?

(In reply to Thomas D. from comment #4)

Alex, Richard, could this be avoided with a min-height?

Yes

Yes

I'm answering here to bug 1635207 Comment 3 since it's more persistent.

• Let's please fix at least the UI overlap problem of bug 1602477 when dragging recipient pane to minimal height.

I'll take care of it.

• Maybe have a default height (internally max-height), which can be adjusted (for current message only) by dragging either way. I think adding 50 recipients in 1 column mode shouldn't cover 90% of my screen by default.

The area already has a default height, which is the one used when opening the compose window for the first time.
There's also a check in place which detects If the height of the header area is bigger than 2/3 of the compose window height, and it enables an overflow.
https://searchfox.org/comm-central/rev/9727e058507d52449d83f08efef8dde232e4ea2c/mail/components/compose/content/addressingWidgetOverlay.js#1049

Does that work as expected? It shouldn't be broken.

(In reply to Magnus Melin [:mkmelin] from comment #9)

Review of attachment 9146062 [details] [diff] [review]:
What is the reason to have the recipient area user resizable in the first
place? All that can do is add some odd white space. We should probably avoid
it.

Resizable upwards is needed for user to control/reduce header area space with many addresses.
Resizable downwards is needed as long as the attachment pane is also in the header, for users who want to temporarily see more of many attachments listed. So in that case, you'll get the odd whitespace, but it's your own choice, we're not forcing anyone to expand like that, so users will only do it when they need it. So I think it's ok.

I repeatedly pasted recipients into the same recipient field, this is the result.
Looks like vertical default limit (internally max-height?) fails to kick in.
However, pls allow user to temporarily change max-height by dragging the splitter either way, iow, we should allow users to drag themselves into this if they need it.

For resize upwards: we should really limit how we allow those fields to grow if we don't already, so that any manual resize is not needed.
Re downwards resizing: talk about non-discoverable things! Sounds like another reason to move the attachments down below (bug 1625263).

The header area should resize automatically when it grows too much

As per this method, which calculates the height of the header area if it grows past 2/3 of the full height of the compose window.
https://searchfox.org/comm-central/rev/9727e058507d52449d83f08efef8dde232e4ea2c/mail/components/compose/content/addressingWidgetOverlay.js#1049

This method applies an scrollable overflow for the recipient fields, and leaves the identity and subject field always visible.
The min-height is necessary to prevent a total overlap of those elements, like shown in the initial screenshot.
That method works for me, Thomas, would you be able to troubleshoot why it doesn't kick in for you?

Resize upwards: Should happen automatically, as per the calculateHeaderHeight() method I linked.
Resize downwards: Shouldn't be necessary unless the user want's to increase the scrollable header area after it's resized by the calculateHeaderHeight() method, so in "normal" scenarios it shouldn't be used at all.

Thanks Richard for the feedback. I'll handle the proper sizing via JS to account for the various OSs, font sizes, and UI scaling of users.

That method works for me, Thomas, would you be able to troubleshoot why it doesn't kick in for you?

FYI, the header area doesn't resize automatically if you previously resized it manually.
That's on purpose to not override the user's decision of expanding that area.

This patch assigns the min-height on creation in order to account for all the different scenarios.
The header area automatically enables an overflow when the amount of pills causes that area to grow past 2/3 of the full compose height.
The area can be then resized based on user's preferences, but it can't be shrunk below the original min-height, or enlarged past the maximum height to prevent UI breakages.

(In reply to Alessandro Castellani (:aleca) from comment #16)

Created attachment 9146255 [details] [diff] [review]
1602477-compose-header.diff

This patch assigns the min-height on creation in order to account for all the different scenarios.
The header area automatically enables an overflow when the amount of pills causes that area to grow past 2/3 of the full compose height.
The area can be then resized based on user's preferences, but it can't be shrunk below the original min-height, or enlarged past the maximum height to prevent UI breakages.

That sounds very good. :-)
Did you tackle the horizontal problem when there's an overlong single pill in a small compose window which can then push things out of screen to the right?

(In reply to Richard Marti (:Paenglab) from comment #17)

I'd like if there would be a max-height for when the user reduces the height
and later can resize downwards and the pane stops automatically when all
content is shown and the pane doesn't show white space because the user
dragged too far.

Where "all content shown" should consider both recipients and attachments - I'd rather accept dragging into a bit of odd whitespace but being able to temporarily see more/all attachments even if they are many.

(In reply to Alessandro Castellani (:aleca) from comment #15)

That method works for me, Thomas, would you be able to troubleshoot why it doesn't kick in for you?
FYI, the header area doesn't resize automatically if you previously resized it manually.
That's on purpose to not override the user's decision of expanding that area.

Maybe that's what I saw. I'll keep an eye on it.

If the user drags the area up, those fields are supposed to disappear and the recipients area turns scrollable.

This patch prevents the header area to completely collapse below its original height, like showed here: https://bug1602477.bmoattachments.org/attachment.cgi?id=9145737

Does that still happen with my patch?

I think it improves things a bit, but not quite. I'll attach a screenshot

You can still drag it up so the fields with content aren't shown, and there is no scrollbar either (though I don't think it should allow fields to hide like that anyway)

This looks like a Ubuntu bug or one from the toolkit implementation. When the scrollbar is too small it hides. Try to drag down a little bit and the scrollbar appears.

Uh, this looks very strange, indeed the scrollbar should be visible.

Thanks for the screenshot.

though I don't think it should allow fields to hide like that anyway.

I think of this as an extreme case when the user deliberately wants to see as much content area as possible and "getting rid" of the header.
By default, this never happens automatically, as the header area resizes to 1/3 of the height of the full window when too many recipients are used to fit in.

I also see this as a quick patch for edge cases to prevent overlaps.
The follow up patch would be to implement a "smart collapse" for those fields where recipients are summarized (mock-up coming)

Something like that (very rough mock-up).
The user can expand the collapsed list to inspect it or change it. Even in this scenario, we need to draggable area if the user wants to view 100 of addresses and control how much of the body content is visible.

P.S. a similar solution could be reused for mailing lists, allowing users to expand them to see the addresses.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/6c1be4cedbac
Implement min-width for the message compose recipient area. r=mkmelin

(In reply to Pulsebot from comment #28)

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/6c1be4cedbac
Implement min-width for the message compose recipient area. r=mkmelin

Looks like wrong commit message :/
You implemented min-height, not min-width.
What about max-width which was also required to fix this bug per summary and comment 0?
Could you file follow-up bugs for max-width and smart collapsing?

(In reply to Thomas D. from comment #29)

Looks like wrong commit message :/

Argh, damn my pandemic brain, I noticed I'm making more and more tiny mistakes and typos of this sort.

Could you file follow-up bugs for max-width and smart collapsing?

Yes, I'll file 2 follow up bugs, on for max-width and the other for smart collapsing.
Thanks for the reminder.

(In reply to Alessandro Castellani (:aleca) from comment #30)

Yes, I'll file 2 follow up bugs, on for max-width and the other for smart collapsing.

Did you have a chance to file them?

Not yet, I'm a bit overwhelmed by the OpenPGP implementation right now, sorry >_>