1714519 - After collapsing and re-expanding composition's attachment pane with several attachments, vertical pane size reduced to 1 line, no scrollbar

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect, P3)

Description

[Jaise]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

In new design, attachment on bottom, expand show only one line of attachments. Balance is not showing.

1. Add 15-20 number of attachment to attachment pane.
2. collapse attachment pane.
3. Again expand

Actual results:

1. It will show only one line of attachment.
2. scroll bar also not showing, since one line is showing.
3. Feel like some attachment missed.
4. If expand attachment pane area to two line, scroll bar appears.

Expected results:

If we expand attachment pane, All attachment should visible. If more than 3-4 line, it will be with scroll bar.

Comment 1

[Thomas D. (:thomas8)]

Attachment: Screenshot1: many attachments after collapse and re-expand

Indeed, this is what happens.

Comment 2

[Thomas D. (:thomas8)]

Alex, can you have a look?

Confirming for 91.0a1 (2021-06-08) (64-bit), Win10.
Happens exactly as described - that's odd and impractical and error-prone.
After adding, it looks good with several lines of attachments showing, but after collapsing and re-expanding, it's reduced to single line without scroll bar.

Comment 3

[Alessandro Castellani [:aleca]]

Thanks for the ping.
There a couple of things here.

When expanding the attachment pane it opens up to only 1 line.
This was decided on purpose during the rework of the attachment UI to keep the code lighter and avoid needless height calculations and thresholds handling height fractions and edge cases where the user might resize the attachment pane, then close it, resize the addressing header area, then reopen the attachment pane with its saved height being taller than the available space.

The final rationales behind the decision of not saving the attachment height and always only expand it to 1 row are:

• The collapsing of the attachment pane is not automatic or unexpected, but is always behind a user action, so the user wants that pane to be closed and there's no need to keep the original height because we don't need to restore a previously lost state.
• We don't restore the previous height also because the compose window height, or the available height of the body might have changed, so we don't always have the same height clearance we might have had before closing. That adds some calculations for edge cases that we preferred to avoid and keep the code simple.

Scrollbar is not visible below 2 rows
If I remember correctly, that's a known core problem of the richlistbox XUL element. I'm not sure we can do anything about it, but I might be wrong.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #3)

Thanks for the ping.
There a couple of things here.

Your quick explanation is appreciated, thanks.

When expanding the attachment pane it opens up to only 1 line.
This was decided on purpose during the rework of the attachment UI to keep the code lighter and avoid needless height calculations [...]
The final rationales behind the decision of not saving the attachment height and always only expand it to 1 row are:

• The collapsing of the attachment pane is not automatic or unexpected, but is always behind a user action, so the user wants that pane to be closed and there's no need to keep the original height because we don't need to restore a previously lost state.

It's not mainly about restoring a previously lost state (as in just saving the last full pane height and restore that), which may obviously be tricky or even impossible if the spatial circumstances have changed. It's about providing a useful UX for the explicit user action of expanding the pane - what are they trying to achieve?

User scenarios for expanding attachment pane

• Check if all desired attachments are present correctly
• Manage attachments: Rename, Reorder, Open to check, Add, Remove

So for a user who deliberately expands the attachment pane to check and manage existing attachments, just showing the last two or three of the lot is unexpected and not useful - in fact, it's a UX fail. Wearing my enterprise hat, this will be a daily nuisance and time-waster - because we are effectively forcing users to expand the pane manually by dragging (after they have already clicked to expand it) every single freaking time they want to check or manage their attachments - a classic "curse Thunderbird 🤬" situation for the lack of ux-efficiency...

• We don't restore the previous height also because the compose window height, or the available height of the body might have changed, so we don't always have the same height clearance we might have had before closing. That adds some calculations for edge cases that we preferred to avoid and keep the code simple.

• Checking and managing attachments is not an edge case.
• "Keep code simple, avoid calculations" is an ux-implementation-level argument - if that's what it takes to provide a useful UX, we just have to bite the bullet.

Scrollbar is not visible below 2 rows
If I remember correctly, that's a known core problem of the richlistbox XUL element. I'm not sure we can do anything about it, but I might be wrong.

Well, it's difficult to show a vertical scrollbar for a single row's height, and it's unlikely to be fixed in the near future. Until then, this may be considered a ux-mode-error, because lack of scrollbar suggests that there's nothing else - users may even start to re-add existing attachments because they can't see them (ux-error-prevention). Apart from that, it just feels wrong and ridiculous that the explicit user action of "Expand the pane" would just provide a tiny glimpse at a fraction of the available attachments when there's enough vertical space to show more or all of them.

I do appreciate that getting this right in code may need a bit of head-cracking (I've been there myself in a related bug for message reader which I can't find right now), but I'm confident that we can do better than this...

Comment 5

[Thomas D. (:thomas8)]

In fact, from an enterprise POV, this may even cause privacy violations because it's easy to end up sending more attachments than intended - a cursory look would suggest that there are only two attachments in screenshot of attachment 9226219 [details], because the rest of them is hidden, and no scroll bar shown.

Comment 6

[Alessandro Castellani [:aleca]]

Attachment: Bug 1714519 - Restore previous height of attachment pane in compose window. r=mkmelin

Comment 7

[Alessandro Castellani [:aleca]]

Well, I'm a silly individual.
It turned out that I actually did implemented this feature during the rework of the attachment pane.
It simply wasn't working because I was setting the height after the uncollapsing of the attachment pane, which apparently XUl doesn't like it.
Setting the saved height before revealing the pane fixes the problem.

I'll add a test to cover this scenario.

Comment 8

[Alessandro Castellani [:aleca]]

Attachment: Bug 1714519 - Restore previous height of attachment pane in compose window. r=mkmelin

Comment 9

[Alessandro Castellani [:aleca]]

try-run: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=b5f47d1fdc3aed73cfc13846d20263706f6c5882

Comment 10

[Jaise]

Attachment: attachment pane.png

Comment 11

[Jaise]

Column view option same like current attachment view for incoming mail is also nice addition.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/29d6ae0ab2a7
Restore previous height of attachment pane in compose window. r=mkmelin