Closed Bug 1602477 Opened 8 months ago Closed 3 months ago

Recipient area needs max-width, min-height and smart collapsing of recipient fields

Categories

(Thunderbird :: Message Compose Window, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 78.0

People

(Reporter: bugzilla2007, Assigned: aleca)

References

Details

Attachments

(5 files, 1 obsolete file)

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.

No longer depends on: 1602470
Summary: Recipient area needs a min-height and intelligent collapsing of recipient fields → Recipient area needs max-width, min-height and intelligent collapsing of recipient fields
Summary: Recipient area needs max-width, min-height and intelligent collapsing of recipient fields → Recipient area needs max-width, min-height and smart collapsing of recipient fields
Version: unspecified → Trunk

(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?

Flags: needinfo?(richard.marti)
Flags: needinfo?(alessandro)

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

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

Yes

Flags: needinfo?(richard.marti)

Yes

Flags: needinfo?(alessandro)

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.

Assignee: nobody → alessandro
Status: NEW → ASSIGNED
Attached patch 1602477-compose-header.diff (obsolete) โ€” โ€” Splinter Review
Attachment #9146062 - Flags: ui-review?(richard.marti)
Attachment #9146062 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9146062 [details] [diff] [review]
1602477-compose-header.diff

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. 
This patch fixes it for the situation of only a To. If you add say a Bcc, then you can still drag the pane above that
Attachment #9146062 - Flags: review?(mkmelin+mozilla) → review-

(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).

Comment on attachment 9146062 [details] [diff] [review]
1602477-compose-header.diff

150px works on Linux. For Mac and Windows it's too much. It's also too much on Linux when you open the composer in plain text mode without the formatting toolbar. I think, the headers-box needs to be calculated after the windows is opened and then set.

I think, we need no ability to make the box bigger than the content is to not show unneeded white space. Could we set a max-height that is calculated from the content? On initial opening the max-height would be the same as the min-height. When adding the Cc field the max-height gets the additional size of the #recipientsContainer now uses. This would let us make the box with the separator bigger until all content is shown. Naturally we need that this max-height isn't bigger than 2/3 of the composer.
Attachment #9146062 - Flags: ui-review?(richard.marti) → ui-review-

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.

Attached patch 1602477-compose-header.diff โ€” โ€” Splinter Review

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.

Attachment #9146062 - Attachment is obsolete: true
Attachment #9146255 - Flags: ui-review?(richard.marti)
Attachment #9146255 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9146255 [details] [diff] [review]
1602477-compose-header.diff

Looks good, thanks.

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.
Attachment #9146255 - Flags: ui-review?(richard.marti) → ui-review+

(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.

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

Review of attachment 9146255 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry doesn't quite work: drag the area down, then add a cc/bcc line. Drag back up- you an now easily drag it above the fields so they disappear.
Attachment #9146255 - Flags: review?(mkmelin+mozilla)

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

Attached image dragup.png โ€”

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)

Attached image compose-collapsed.png โ€”

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.

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

Review of attachment 9146255 [details] [diff] [review]:
-----------------------------------------------------------------

We talked about this and will go with this for now even if its not perfect.
Attachment #9146255 - Flags: review+
Target Milestone: --- → Thunderbird 78.0

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

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED

(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?

Flags: needinfo?(alessandro)

(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.

Flags: needinfo?(alessandro)

(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?

Component: Composition → Message Compose Window
Flags: needinfo?(alessandro)
Product: MailNews Core → Thunderbird
See Also: → 1609895

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

Flags: needinfo?(alessandro)
You need to log in before you can comment on or make changes to this bug.