707432 - Composition: Implement / add context menu for right-click on attachment pane header bar's "X attachments" and "{size}" labels (shortcut to actions for all attachments, and adding attachments)

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement)

Description

[Thomas D. (:thomas8)]

Attachment: Proposed UI (draft): attachment header bar context menu for composition

In analogy to what we've done well for 3 pane attachment panel in
Bug 680695 - Implement / add context menu with actions for all attachments for right-click on [paperclip icon], "X attachments" or [size] labels of attachment bar,
we should have the same efficiency and comfort for composition:

STR
1) On attachment pane's header bar, right-Click on "X attachments [size]" labels (as we can now do in 3-pane)

Actual
- nothing

Expected
- offer something useful :)
- internal ux-consistency with bug 680695 for 3-pane, where we can now right-click on attachment header bar's "X attachment [size]" labels to get at relevant actions :)
- show context menu with following relevant actions:

a) for "X attachments" with X > 0 (one or more attachments have been added):

+----------------------++-----------------------+
| Attach             > ||  File(s)...           |
+----------------------||  Web page...          |
| Open All (1)         |+-----------------------+
| Remove All           ||  Personal Card (vCard)|
| Rename All (2)       |+-----------------------+
+----------------------+
| Select All           |
+----------------------+

(1): "Open All" is not yet enabled (bug 707422)
(2): "Rename All" is not yet enabled (needs new bug)

b) for "0 attachments" (user has removed all attachments to start from scratch, disable all-attachment actions):
- "/" indicates a disabled menu item - 

+----------------------++-----------------------+
| Attach             > ||  File(s)...           |
+----------------------||  Web page...          |
|/Open All             |+-----------------------+
|/Remove All           ||  Personal Card (vCard)|
|/Rename All           |+-----------------------+
+----------------------+
|/Select All           |
+----------------------+

Blake, Jim, let me know if you need an interactive version to visualize this. Feedback welcome.

N.B. Of course, I was also thinking whether left-click on attachment header bar should open "Attach file" dialogue, but that might need some more reflection.

Comment 1

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 578832 [details]
Proposed UI (draft): attachment header bar context menu for composition

>STR
>1) On attachment pane's header bar, right-Click on "X attachments [size]" labels (as we can now do in 3-pane)
>- internal ux-consistency with bug 680695 for 3-pane, where we can now right-click on attachment header bar's "X attachment [size]" labels to get at relevant actions :)

For actual consistency, I would expect that clicking an empty area show the same menu.

>+----------------------++-----------------------+
>| Attach             > ||  File(s)...           |
>+----------------------||  Web page...          |
>| Open All   (1)       |+-----------------------+
>| Remove All           ||  Personal Card (vCard)|
>| Rename All (2)       |+-----------------------+
>+----------------------+
>| Select All           |
>+----------------------+

Since there aren't a ton of things in the attach menu, I don't see why we wouldn't just put those options inline.
And I think "Select All" is sufficiently similar to "Open All"/"Remove All"/"Rename All" to remove the separator between them.

That would leave us with:
+----------------------+
| Attach File(s)...    |
| Attach Web Page...   |
| Attach Personal Card |
+----------------------|
| Open All             |
| Remove All           |
| Rename All           |
| Select All           |
+----------------------+

But in general, this seems like a reasonable idea.

Comment 2

[Thomas D. (:thomas8)]

Attachment: Patch V. 1

Richard,

I would like to expose the attachment list context menu more, and make this consistent with message reader UX, where we have the same structure of context menus. The idea is that "3 attachments" label (and, by extension, the size label) is like an object representing the attachments, so it makes sense to right-click on that for contextual actions. Otherwise, it doesn't hurt in any way nor eat ressources, as we're just adding a passive context="..." attribute.

Benefits:
- ux-consistency with message reader attachment header context menus
- expose attachment list context menu more (often not reachable when there's no attachment pane whitespace, and currently broken when no items selected and pressing context menu key, xul bug which we fixed for contacts side bar)
- always accessible, in-place contextual actions (especially now as the attach button is still far away on the left)
- zero costs
- f+ by bwinton (comment 1)

Comment 3

[Richard Marti (:Paenglab)]

Comment on attachment 8960466 [details] [diff] [review]
Patch V. 1

This works as designed. But I'm not happy with this together with bug 1437305. Then we have two different context menus on three places in most of the time a small area. It can happen when you don't point precisely on the text but a bit below or above it, that the initial show bucket initially menu is shown.

What about combine both and show the show bucket intially menuitem only in the header?

Comment 4

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #3)
> Comment on attachment 8960466 [details] [diff] [review]
> Patch V. 1
> 
> This works as designed. But I'm not happy with this together with bug
> 1437305. Then we have two different context menus on three places in most of
> the time a small area. It can happen when you don't point precisely on the
> text but a bit below or above it, that the initial show bucket initially
> menu is shown.

That would just help with ux-discovery of "Initially Show Attachment Pane" ;-)
But honestly, it takes considerable effort to miss the context menu on the labels, which is a click target about 22px high, it's quite hard to miss that and end up exactly on the 3px above and below the label...
We have exactly the same UI in message reader's attachment pane header, and no one ever complained, so I'd think we'd be on the safe and easy side to just duplicate that, no?

> What about combine both and show the show bucket intially menuitem only in
> the header?

How useful is "Initially Show Attachment Pane" on a regular context menu with attachment-related actions? How often will it be used? Imho (as mentioned before), having this on any regular context menu would just be permanent clutter without any real purpose, given that "Initially Show Attachment Pane" is most likely to be used exactly *once* on a given installation, or maximally "once in a blue moon". That's not worth more exposure, and just distracts from the relevant actions (violating ux-minimalism, reducing relative ux-discovery of other items). If we want to expose this more, let's create an entry somewhere in Tools > Options.

There's nothing special about having several different right-click targets on a toolbar. Please try right-clicking across the Firefox main toolbar (with address bar). There's a different context menu at every inch of that:
- Right-click on back/forward shows history context menu (*not* the button/toolbar context menu; so that's same by analogy as our "5 attachments" (and "4 MB"), a more frequently used special-purpose target)
- Right-click on regular toolbar buttons like "Refresh" shows combined context menu: button-specific and toolbar context.
- Right-click on address input shows text box context menu (*not* the toolbar context menu)
- Right-click on *** button shows nothing
- Right-click on pocket button or star button shows "Remove from address bar" only
- Right-click on a separator shows button-specific context (disabled) and toolbar context.

Comment 5

[Richard Marti (:Paenglab)]

Your examples are on toolbars which are normally wide. The attachment header is normally around 200px wide and depending of the locales text length it has not much in between. Also are this all buttons and the attachment header has no functionality except the close button.

Comment 6

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #3)
> Comment on attachment 8960466 [details] [diff] [review]
> Patch V. 1
> 
> This works as designed. But I'm not happy with this together with bug
> 1437305. Then we have two different context menus on three places in most of
> the time a small area.
> What about combine both and show the show bucket intially menuitem only in
> the header?

Ok, let's follow your proposal and add |Initially Show Attachment Pane| menu item to the attachment list context menu, which (after this bug) will be displayed when right-clicking |X attachments| or the size label. I'll add the menu item in bug 1437305 where it belongs. In the header blank space, we've agreed to only have |Initially Show Attachment Pane| (bug 1437305). So with both bugs, we'll have |Initially Show Attachment Pane| accessible all accross the header as you said, for bigger click target.

So I think the patch here is right and we do the rest in bug 1437305, so can you please change r- into r+.

> It can happen when you don't point precisely on the
> text but a bit below or above it, that the |Initially Show Attachment Pane|
> menu is shown.

As explained in my comment 4, I think missing a 22px high click target and hitting exactly the 3px margin at top/bottom of the label is all but impossible, and nothing bad happens even if you do. If you really want to fix this, pls suggest a way (XUL/CSS) so that the labels as a click target cover the full height of the containing box. I wouldn't hold up this bug for that unlikely and trivial "edge" case (Firefox toolbar buttons do get that right somehow).

Comment 7

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere) from comment #6)
> > It can happen when you don't point precisely on the
> > text but a bit below or above it, that the |Initially Show Attachment Pane|
> > menu is shown.
> 
> As explained in my comment 4, I think missing a 22px high click target and
> hitting exactly the 3px margin at top/bottom of the label is all but
> impossible, and nothing bad happens even if you do. If you really want to
> fix this, pls suggest a way (XUL/CSS) so that the labels as a click target
> cover the full height of the containing box. I wouldn't hold up this bug for
> that unlikely and trivial "edge" case (Firefox toolbar buttons do get that
> right somehow).

Maybe I was wrong, we should try to fix this. Ideas?

Comment 8

[Thomas D. (:thomas8)]

Current plan is to fix this in bug 1437305, whichever is faster.
But we can play with nitfixing the details of comment 7 here.

Comment 9

[Richard Marti (:Paenglab)]

This should work:

<hbox id="attachments-header-box"
      align="stretch">
  <hbox id="attachmentBucketCountBox" align="center"
        context="msgComposeAttachmentListContext">
    <label id="attachmentBucketCount"/>
  </hbox>
  <toolbarspring/>
  <hbox id="attachmentBucketSizeBox" align="center"
        context="msgComposeAttachmentListContext">
    <label id="attachmentBucketSize"/>
  </hbox>
  <hbox id="attachmentBucketCloseButtonBox" align="center">
    <toolbarbutton id="attachmentBucketCloseButton"/>
  </hbox>
</hbox>

The context menu should be placed on the hboxes to appear on the full height.

Comment 11

[Thomas D. (:thomas8)]

I fixed this with patch #2 (attachment 8980879 [details] [diff] [review]) in bug 1461170.

Comment 12

[Thomas D. (:thomas8)]

Sorry for the noise of flipping dependencies.