Closed Bug 1100103 Opened 5 years ago Closed 2 years ago

Add a remove button to every To/CC/BCC address in Composer

Categories

(Thunderbird :: Message Compose Window, enhancement)

31 Branch
enhancement
Not set

Tracking

(thunderbird60 fixed, thunderbird61 fixed)

RESOLVED FIXED
Thunderbird 61.0
Tracking Status
thunderbird60 --- fixed
thunderbird61 --- fixed

People

(Reporter: marcoagpinto, Assigned: Paenglab)

References

Details

Attachments

(6 files, 4 obsolete files)

Pressed the button to create a new message

The To/Cc/Bcc selected recipients appear in lines

This is just an idea to improve it:
They should appear in editor gadgets just like in Outlook, but with some improvements like in the screenshot of Moodle 2.5 of the university I work for.

Notice the "Professor" with the red "x". I think this is made in JavaScript since the "professor" is text when you try to select with the mouse.
[14:26] <clokep> I don't understand what that screenshot is trying to show. :-\
[14:27] <marcoagpinto> clokep: the names of the recipients: "Marco Pinto x" "Aceman x"
[14:27] <marcoagpinto> each name should appear like that in the editor gadget
[14:27] <marcoagpinto> then people should be able to delete them by clicking in the "x"
Address Close Button addon will get you the X
Summary: Improve To/Cc/Bcc UI → Add a remove button to every To/CC/BCC address in Composer
[14:28] <clokep> marcoagpinto: So you're just suggesting a small x appear so they can be deleted?
[14:28] <marcoagpinto> yes
[14:28] <marcoagpinto> :)
[14:28] <clokep> Have you seen JosiahOne's plans to totally redo the To/CC/BCC lines of the editor?
[14:28] <marcoagpinto> and a box for each
[14:29] <marcoagpinto> a box for To, other for Cc and other for Bcc

I also wanted to mention a box just like Outlook uses, with multiple recipients inside each.
Attached image proposed copy β€”
Shouldn't we have something like this? :)
Suyash, yes. That's very similar to my proposal, except the X will actually be a drop down icon to list options for the address. Regardless, this bug is kind of obsolete because of that bug.
sshagarwal: That is what I meant :p

Thanks for the screenshot which is better than my silly text.
(In reply to Marco A.G.Pinto from comment #6)
> sshagarwal: That is what I meant :p
> 
> Thanks for the screenshot which is better than my silly text.
Nevermind :)

(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #5)
> Suyash, yes. That's very similar to my proposal, except the X will actually
> be a drop down icon to list options for the address. Regardless, this bug is
> kind of obsolete because of that bug.

Cool! So, can you please mention that bug so that the reporter can be convinced
and we can mark this bug as a dupe(?) or anything else that shows this is being
solved by that?

Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 440377
From a bug management perspective, this bug is not a duplicate of bug 440377:

1) This bug is also filed and valid against the current multiline layout; we never know when bug 440377 will actually land and it might very well be possible and faster to land an easy fix for this in the current layout (make an X appear on hovering address lines, or add an X to every address line).

2) Bug 440377 may or may not implement this exact functionality as requested here, and Josiah's tentative comment 5 suggests it might be done in a different way which does not provide the efficiency suggested here. So if bug 440377 actually implements this in a satisfying way, we can still close this, but until then, it's a bug in it's own right.

And of course, it's a long known issue already reported...
Duplicate of bug: 143147
Could someone implement this add-on?

It is just 3 kB long.

https://addons.mozilla.org/en-US/thunderbird/addon/address-close-button/?src=search
Is the addon not working in TB52+ ?

Looking at the addon, the feature is basically 3 lines of XUL plus some css to style the icon and the icon itself.
This could be easily implemented in base TB if accepted by UX.
There are some things to note though:
1. adding an icon to every recipient could be heavy (perf/memory). I'll test it on a message with thousands of recipients (which some users asked for). Maybe we could use some lighter X character.
2. clicking the icon does not only clear the recipient address, it removes the whole recipient row, also with the type picker (To/CC/BCC). So maybe the icon could be placed elsewhere, e.g. before the whole row, or the end of it.

Note that Outlook does not have it, because there the recipients aren't plain text, but objects that can be moved or deleted as a whole. In TB you have to delete the recipient as text and also the whole row.
So I can understand the benefit of this feature.
Flags: needinfo?(richard.marti)
Yes, this looks simple to implement. But maybe instead of the close icon we could use the delete icon. And it should also be accessible by key. I think we should add a button at the end of the row. Inside the textbox could give problems with different text sizes.

But then this should be implemented in bug 143147 and not in this duped one.
Flags: needinfo?(richard.marti)
The duping to bug 440377 is to be cut unless anybody wants to implement that one sooner.
Otherwise we can do this one fast.

Yes, bug 143147 is the same. We could keep one for SM and one for TB.

Marco, please email the author of the addon if he wants to implement the feature in core TB, with the changes from comment 12.
If he doesn't we can do it.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(marcoagpinto)
Resolution: DUPLICATE → ---
Well, I found the guy's e-mail address in the rdf, but it seems to not exist any more.

:-(

So, there is no way to reach him.
Flags: needinfo?(marcoagpinto)
(In reply to :aceman from comment #11)
> Is the addon not working in TB52+ ?
Works in Daily TB 60.

(In reply to Richard Marti (:Paenglab) from comment #12)
> I think we should add a button at the end of the row.
Yes.
It sounds lame to move the button action away from the name.  Not great for eye-hand coordination
(In reply to Wayne Mery (:wsmwk) from comment #16)
> It sounds lame to move the button action away from the name.  Not great for
> eye-hand coordination

If we would have multiple addresses per row, yes. But with one address per row it's also more clear that the whole row will be removed.
(In reply to Wayne Mery (:wsmwk) from comment #16)
> It sounds lame to move the button action away from the name.  Not great for
> eye-hand coordination

+1, 100%.

(In reply to Richard Marti (:Paenglab) from comment #17)
> If we would have multiple addresses per row, yes. But with one address per
> row it's also more clear that the whole row will be removed.

I don't think there'll be much surprise about row removal given that we currently have a row-based recipient design. Removing a recipient is removing the row. But on wide screens, the ❌ can end up miles away from the name, which is really counter-intuitive as Wayne says.
Here's my ideas for the UX/design of this:

1.) X-button right after the recipient's name (ux-in-place, ux-efficiency, ux-consistency):
John Doe ❌

Far-end violates ux-in-place, ux-efficiency, and it's just odd, actually ux-implementation-level, making our non-standard tabular implementation stand out even more, and further reducing external ux-consistency with other agents where each recipient is a block which can be deleted in-place.

That said, the only reason for having ❌ at the end of the row would be higher efficiency for multiple deletions, but I think we need to come up with something smarter for that, maybe checkboxes and a floating action menu.

2.) Show X-button only on hover of the recipient row(sic!), not always (ux-minimalism):
John Doe        (normal state)
John Doe ❌      (row hovered state)

Nobody needs or wants dozens of ❌ permanently on the screen, and imo deleting recipients isn't a frequent enough action to justify that visual clutter. Maybe if they are *very* light and only get color on hover, but still. Also, there's near-zero difference in efficiency because you'll have to move onto that recipient anyway, so as you're moving, you'll see your ❌ target just when you need it.

3.) Use only plain unicode ❌ character for better performance, this must scale efficiently even for 1000 recipients, so no graphics please (ux-minimalism, performance). I think plain and simple ❌ is just fine, imo no other button effects, backgrounds etc. required. Maybe a css hover effect on the ❌.
http://www.fileformat.info/info/unicode/char/274c/browsertest.htm
Yeah, far end may be too far to travel by hand.
Maybe before the recipient input field or even before the To/CC picker.
The button could show on mouse hover or when the particular recipient textbox has focus. Something like IE11 has in the URL bar history (X appears to remove hovered entry you typed into the URL field).
Attached patch deleteAddress.patch (obsolete) β€” β€” Splinter Review
aceman, can you try this with many addressees to see if this slows down too much?

I'm using our delete SVG icon instead the close icon. With this it's more clear for what it is.
Attachment #8953223 - Flags: review?(acelists)
Comment on attachment 8953223 [details] [diff] [review]
deleteAddress.patch

Sorry, but that's really ugly :-(
There should be a little X following the address, not a trash can preceding it. Also, when you hover the field to enter the address, before it's even entered completely, you see the trash can. We want to delete entered addresses, not see the trash can while entering them. So nothing should show on hovered empty fields or while the auto-complete is still in progress. I guess this needs a whole lot more JS code to do.
Hello!

What about sshagarwal attachment above from years ago?

The icon could look like that and the "x" become red while hoovered.
Hello!

What about sshagarwal attachment above from years ago?

The icon could look like that and the "x" become red while hoovered.

Guys, take a look at my Moodle screenshot example above, it should look something like this.
(In reply to Richard Marti (:Paenglab) from comment #21)
> Created attachment 8953223 [details] [diff] [review]
> deleteAddress.patch
> 
> aceman, can you try this with many addressees to see if this slows down too
> much?

Interestingly, this didn't add any time to open a message with thousands of recipients.
Maybe the trick with the icon having width of 0 makes it not load/render in any way so it takes no time.
Only when an address is hovered the icon appears.

It would be better if the address wasn't moved when the icon appears.
I also got into cases where 2 rows had the icon, but those are hard to reproduce. Some may be caused by generally very slow display of recipients when there are many.
Can't someone give review+ to the current icon?

Then, later, if a better one appears it can be replaced?

The important is to have the feature on.

Thank you!
Comment on attachment 8953223 [details] [diff] [review]
deleteAddress.patch

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

Me and Jorg have provided some comments on what should be improved here. The recipient should not jump around, and the icon should be more subtle.

::: mail/components/compose/content/messengercompose.xul
@@ +1095,5 @@
>                    </menupopup>
>                  </menulist>
>                </listcell>
>                <listcell class="addressingWidgetCell">
> +                <image id="deleteAddress"

This element will be replicated for each recipient row, so it can't have an ID, only a class.
Attachment #8953223 - Flags: review?(acelists)
I've played around with the patch, but I haven't been able to achieve anything desirable.

Basically you have this:
              <listcell class="addressingWidgetCell">
                <textbox id="addressCol2#1" class="plain textbox-addressingWidget uri-element"
                         aria-labelledby="addressCol1#1"
                         type="autocomplete" flex="1"
                         ...
                </textbox>
              </listcell>
and you can place you image into the listcell, either before the textbox or after the text box.

Before the text box it's very prominent. And transition ("jumping") proposed in the patch doesn't make it better. Also, it's always there, even when no address has been entered or when the address is being entered.

What we'd like to have, a small [x]-style icon *in* the text box isn't possible. What is suggested in comment #19 is nice and I agree, but I don't see how that would be doable technically. It might be possible to place the ❌ after the address text with some CSS trick, but it would still be part of the text in the textbox and hence no delete action could be tied to it when essentially clicking onto the address itself text. I'd be very happy to be proven wrong on this one.

So I think the best way out here is to place a non-moving icon after the text box. That had its opposition, but we need to consider the case when the ❌-button would be used. That's mainly when replying to all and we get many undesired recipients we need to remove. Well, in this case, move the mouse to the right and click all the ❌'s. Yes, you need to follow the row to the left, not great for eye-hand coordination.

Someone with a better idea that can be implemented, please step forward.

Or how about this:

To: ___ Thomas ...

The ___ is essentially grey like the background of the "To:". When you hover that area, a small [x] appears that you can click.
Attached image 1100103-mockup.png β€”
This should be doable. If the area is not hovered, so during address entry, the [x] doesn't show. It only shows when hovered.
Attached patch deleteAddress.patch (JK) (obsolete) β€” β€” Splinter Review
Something like this. The icon needs to be a little [x] and it needs to be smaller.
(In reply to Jorg K (GMT+1) from comment #31)
> Created attachment 8959848 [details]
> This is the idea

This is for me ugly. The addresses aren't aligned with the sender and subject fields. That's why I made the button hiding when the focus isn't in the boxes.
Yes, it destroys the alignment. Can you do it a little more like the add-on does, it seems that the image sits in the cell. But I'd only show the image when hovered.
And this is the problem. On Linux this makes the textbox grow.
(In reply to Jorg K (GMT+1) from comment #28)
> What we'd like to have, a small [x]-style icon *in* the text box isn't
> possible. What is suggested in comment #19 is nice and I agree, but I don't
> see how that would be doable technically.

Certainly non-trivial, but certainly doable if we're determined.
I don't have time to look into this in more detail, but I'd envision something like this:

The listcell or even some other parent element higher up the tree gets an onhover listener.
Listener function:
event.explicitOriginalTarget (or something like that) to get the textbox element.
Get the text node inside the text box, and the absolute coordinates of the text node's box.
Use js to insert the x button element after the text box element (.insertAfter), and then js again to reposition the x after the text, using the absolute coordinates of the text end.
x button element upon creation gets a target function call including reference to the current recipient element which must be deleted when clicked.
(In reply to Thomas D. from comment #35)

> Get the text node inside the text box, and the absolute coordinates of the
> text node's box.
> Use js to insert the x button element after the text box element
> (.insertAfter), and then js again to reposition the x after the text, using
> the absolute coordinates of the text end.

Or if we succeed to get the text node inside the text box node, maybe we can just insert our x node after the text node (inside the text box), and maybe have something like a span tag around it which holds the function call.

> x button element upon creation gets a target function call including
> reference to the current recipient element which must be deleted when
> clicked.
Highly non-trivial. You're actually suggesting to dig around with the internals of the XUL element. Then we might as well not do it and wait for bug 440377 as Wayne suggested recently on IRC. There we'll have to redo the entire widget anyway and might include the [x] as suggested by attachment 8523518 [details].
Same patch almost, just like this:
              <listcell class="addressingWidgetCell" align="stretch">
                <image id="deleteAddress"
                       onclick="awDeleteHit(this);"/>
                <menulist id="addressCol1#1" disableonsend="true"
                          class="aw-menulist" flex="1"
                          oncommand="onAddressColCommand(this.id);">

Any good?
Attached patch deleteAddress.patch (obsolete) β€” β€” Splinter Review
This time with the icon as the first of the line. I'm using the X because everybody wants to close the address and not delete it. I acquiesce me to the majority (I'm Swiss ;) ).

This still shows the icon when hovering the line also when the field is empty.
Assignee: nobody → richard.marti
Attachment #8953223 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #8959952 - Flags: review?(jorgk)
Comment on attachment 8959952 [details] [diff] [review]
deleteAddress.patch

This is very nice. But please only make the [x] show up when you hover the the To/Cc/Bcc, not when hovering the address. When I'm capturing the address, I don't need the [x] to show.

If we can have this soon, I'm happy to ship this in the beta we're currently building.
Attachment #8959952 - Flags: review?(jorgk) → feedback+
Attached patch deleteAddress.patch (obsolete) β€” β€” Splinter Review
Like this? I made the animation also a bit faster.
Attachment #8959952 - Attachment is obsolete: true
Attachment #8959954 - Flags: review?(jorgk)
Comment on attachment 8959954 [details] [diff] [review]
deleteAddress.patch

Yes, like hits, thanks. Should we get Aceman's feedback?
Attachment #8959954 - Flags: review?(jorgk)
Attachment #8959954 - Flags: review+
Attachment #8959954 - Flags: feedback?(acelists)
Much nicer, thanks. But the icon now shortens the recipient type picker and when you open the popup, icon still stays and the labels in the popup are truncated now.
(In reply to :aceman from comment #44)
> Much nicer, thanks. But the icon now shortens the recipient type picker and
> when you open the popup, icon still stays and the labels in the popup are
> truncated now.

How about this? It's a bit a hack, but shows the whole menulist when open. The X isn't shown when the menulist closes, but is it then needed?
Attachment #8959980 - Flags: review?(jorgk)
Attachment #8959980 - Flags: review?(acelists)
Attachment #8959980 - Attachment description: deleteAddress.patch → deleteAddress.patch with full width menulist when open
Comment on attachment 8959980 [details] [diff] [review]
deleteAddress.patch with full width menulist when open

Tricky, but nice. For my taste, the popup wasn't too narrow, I could still see To: Cc: and Bcc:. Some items are truncated even now.
Attachment #8959980 - Flags: review?(jorgk) → review+
Yes, some items are truncated even without this patch. That looks kinda ugly. The default strings should be fully visible.
I hope localizations can expand the picker in some way.
Comment on attachment 8959980 [details] [diff] [review]
deleteAddress.patch with full width menulist when open

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

Yes, I like this too. But please expand the size of the dropdown to about 17ch which makes them fully shown (for en-US on my Linux).

I have tested this on a message with 4000 recipients.
Everything is slow in such a compose window.
The delete icon takes a 1-2 SECONDS to fully show/expand, but that is still the much faster way to remove recipients in such a composition. Deleting them manually by backspace is much slower as processing each keystroke takes a second.

I tried to remove the animation, but it does not help. Just any change in the UI (e.g. the icon appearing immediately) is slow with so many recipients.
So I think this is OK.
Attachment #8959980 - Flags: review?(acelists) → review+
Thanks. I think we should change the width in a new bug.
Keywords: checkin-needed
Attachment #8959954 - Attachment is obsolete: true
Attachment #8959954 - Flags: feedback?(acelists)
Comment on attachment 8959980 [details] [diff] [review]
deleteAddress.patch with full width menulist when open

A good candidate for beta.

Don't tell Marco this will land in TB 60. ;)
Attachment #8959980 - Flags: approval-comm-beta?
Attachment #8959980 - Flags: approval-comm-beta? → approval-comm-beta+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/8a24899e36cd
Add a delete button in front of the recipient row in the composer. r=aceman,jorgk
Status: ASSIGNED → RESOLVED
Closed: 5 years ago2 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 61.0
Depends on: 1446878
Target Milestone: Thunderbird 61.0 → Thunderbird 60.0
No, landed on TB 61 and got uplifted. Target Milestone: Thunderbird 61.0.
Target Milestone: Thunderbird 60.0 → Thunderbird 61.0
See Also: → 1493158
You need to log in before you can comment on or make changes to this bug.