K-9: Cut/copy of recipient address do copy an empty list to the clipboard

[wwp]

When copying/cutting one or more addresses from the recipient fields of a compose/reply form to the clipboard, it's an empty list that is copied instead (you get a pair of ",," - without the quotes - per address copied).

How to reproduce:

• reply to an email
• long press the To: address, 'select all' then 'copy'.
• go and paste elsewhere: you get for instance ",," (if one address copied) or ",, ,, ,," (3 addresses copied).

K-9 Mail version:
5.111

Android version:
6.0.1

[cketti]

I'm not sure how we're going to handle this. Gmail for example doesn't seem to support selecting/copying from the recipient fields.

[wwp]

Copy/paste for _any_ edit field, where typing is free or more or less free, is a minimum required in terms of GUI usability. What kind of difficulty are you facing here, BTW (just learning the internals) ?

[wwp]

BTW, in Gmail for Android:

• while reading an email, long-pressing a recipient will pop a dialog up: you can either send email or copy.
• while composing, long-pressing in a recipient field shows up the select/copy/paste menu, as expected in any edit field.

[cketti]

Let's not conflate issues. This is about the screen when composing messages.

While Gmail shows the 'Paste/Select All' popup for me, it doesn't actually allow you to select any text. I'm guessing that's mainly because it's hard to get right. The "recipient boxes" mostly only show the display name, not the email address. In Gmail you can long-press such a recipient box to get a dialog that allows you to copy the email address. Sadly, that's not easily discoverable.

I believe it should be possible to insert the email addresses when one or more recipient boxes are selected and copied in K-9 Mail. However, the selection handles are also behaving weird when recipient boxes are part of the input field.
This certainly needs some attention, but I don't think it'll be an easy fix. I don't want to block the next stable version because of this.

Of course, pull requests to fix this issue are more than welcome.

[Dave-Rado]

It used to work fine when it was text instead of a token, which it was in K-9 Mail on my phone until only a few days ago. Why can't you simply revert to displaying it as text, as in:

Displayname <[e-mail]>

That would solve both the bug described in this thread and the much more serious problem described in thread #1925.

Dave

[philipwhiuk]

1. Because the tokens display useful information aside from display name and address.
2. Because displaying it like that is ugly.

[Valodim]

Having tokens like this optimizes for the common workflow, which is sending an email to a contact. It also allows us to display auxiliary information (like availability of a pubkey).

We recognize that a number of other workflows got worse with this change, and we're sorry about that inconvenience. We don't have the developer resources to provide feature parity from day one for these types of changes. What we have to do now is figure out how to deal with those problems and support these workflows again, ideally in a better way than before :)

I took a stab at adding drag and drop here, check out #2138. If done right, that should solve moving recipients between To/Cc/Bcc at least.

[cketti]

This is fixed in K-9 Mail 5.7xx.