1602461 - Allow pasting pills or plain text via Ctrl+V/Cmd+V when other pills of target addressing field happen to be still selected

Status: NEW

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

Description

[Thomas D. (:thomas8)]

I am looking at the latest available iteration of bug 440377 (try build 73.0a1 (2019-12-06) (64-bit).*

This RFE is all about keyboard convenience: If pills are selected, and the user pastes something into the focused addressing row using Ctrl+V - what is the benefit of ignoring that obvious intention, doing nothing and forcing the user to deselect first? It's a useless inconvenience.
This RFE is explicitly not about mouse behaviour.

STR [Edited]

1. Drag some pills into To-field so they are still selected (or just select them now).
2. Copy an email address from outside Thunderbird.
3. Use a keyboard method of refocusing the TB window (to preserve pill selection), e.g. Alt+Tab.
4. So with an existing selection of pills including one focused pill in To-Field, paste using Ctrl+V.

Actual result

• nothing

Expected result

• insert pasted pill(s)
• do NOT replace selected pills in target area (err on safe side, cf. Windows Explorer behaviour)

*: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9

Comment 1

[Alessandro Castellani [:aleca]]

How do you think we should handle the past if pills from different recipients are selected?
If the user currently selected a pill from the CC field and a pill from the TO field, and hits ctrl+v, should both CC and TO receive the copied values?
If not, which one should have priority?

I'm not sure if this implementation is really necessary as it's a bit counter intuitive to expect a field to receive a paste action when the field is not selected/focused.

Thoughts?

Comment 2

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani (:aleca) (PTO to 17th Jan 2020, sporadically reading bugmail) from comment #1)

How do you think we should handle the past if pills from different recipients are selected?

Good point. Certainly an edge case, but if we allow simultaneous selection across recipient types, it must be handled.

If the user currently selected a pill from the CC field and a pill from the TO field, and hits ctrl+v, should both CC and TO receive the copied values?

No, that would be unexpected and not useful. Selections can receive keyboard input (e.g. DEL), but this a pretty extraordinary type of selection and it just doesn't make sense to paste into two different fields at once, and that would be quite unheard of.

If not, which one should have priority?

If it's not selection, keystrokes must correlate to keyboard focus. So I think in this case, the most predictable behaviour is to paste into the field which has keyboard focus (one pill with keyboard focus ring). Btw, keyboard focus ring on selected pill is pretty much invisible right now - can we make that more visible? maybe dotted blue border?

I'm not sure if this implementation is really necessary as it's a bit counter intuitive to expect a field to receive a paste action when the field is not selected/focused.

I'm not sure if I understand you here, but I guess it's in line with my proposal: Paste action should go into the field with keyboard focus, which is only one field even when cross-field selections are present.

Comment 3

[Thomas D. (:thomas8)]

We also need to handle cases where plain text like "Doe, John" or "Jane" (without valid email addresses) gets pasted while pills are selected. E. g. when user has copied a display name and for reasons only known to himself, selects some pills before pasting that display name.

Comment 4

[Alessandro Castellani [:aleca]]

I don't think we should implement this.
A paste action should happen only if the target element allows it by default.
On bug 1602456, I'm triggering the generation of pills only if the currently focused target is an addressing field.

Once again, enabling this option doesn't make sense as it opens up to unnecessary complexity:

• The user maybe expects the select pills to be replaced by the paste action.
• If multiple pills from multiple addressing fields are selected, what is the focused row to use?
• Enabling a behaviour that doesn't make sense in forms.

The compose header is first and foremost a web form with input fields and custom elements.
Pushing these changes to behave like a Windows Folder doesn't make sense to me.

I'll set P3 to leave it in the backlog and see how users react once the next beta is out, but to me this is mostly WONTFIX.

Comment 5

[Thomas D. (:thomas8)]

Mass-changing bugs around the new recipient area (pills) from product/component MailNews Core/Composition to Thunderbird/Message Compose Window, because composition frontend code is not shared with SM. Mostly cloned from Bug 440377 which started out in MailNews Core long back.

20200614002RecipientPillsProductChangeTypeEnhancement

Comment 6

[Thomas D. (:thomas8)]

xref bug 1666076 which is different from this bug 1602461.
The other bug 1666076 expects selected pill (or pills?) to be overwritten upon typing just like selected text, whereas here we're item-centric and want to preserve selected items and just paste alongside them.

This RFE is all about convenience: If pills are selected, and the user pastes something into the addressing row using Ctrl+V - what is the benefit of ignoring that obvious intention, doing nothing and forcing the user to deselect first? It's a useless inconvenience.
I should point out that this RFE is really only about using Ctrl+V keyboard shortcut for pasting, because for mouse use, the problem will not occur, for the moment you click somewhere, we'll deselect and refocus (and you wouldn't typically try to mouse-paste on a selection).
This RFE accepts that pills are items and should have the well-known default behaviour of items in a container (best seen in Explorer).

(In reply to Alessandro Castellani (:aleca) from comment #4)

I don't think we should implement this.
A paste action should happen only if the target element allows it by default.

The perceived target element is the addressing row, which does allow pasting.

Once again, enabling this option doesn't make sense as it opens up to unnecessary complexity:

Quite the opposite. This RFE makes things simpler, because pasting will succeed without forcing the user to deselect first.

• The user maybe expects the select pills to be replaced by the paste action.

To err on safe side can never cause a problem. First and foremost, user wants to paste, he's pressing Ctrl+V for a reason, not as a joke. So we should paste. Replacing selection or not is a question of UX philosophy:

• if we understand selected pills as selected text, we may expect that to be overwritten. Not replacing won't be harmful, even if the user expected that. It will be obvious from the UI that the selection has not been replaced.
• if we understand selected pills as selected items in a container, the default behaviour is not overwriting them, but deselect and paste in the container, so that explicit paste action succeeds, for the user's convenience.

• If multiple pills from multiple addressing fields are selected, what is the focused row to use?

Simple, as explained in comment 2, there is only ever one row which has keyboard focus (focused pill), so obviously we have to use that for Ctrl+V. Mouse contextual paste will automatically focus the right target.

• Enabling a behaviour that doesn't make sense in forms.
  The compose header is first and foremost a web form with input fields and custom elements.

I don't think that implementation-level arguments should define UX.
If we take pills as items, they should have useful item behaviour.
Forcing the user to deselect before being able to paste new items via keyboard is inconvenient.

Pushing these changes to behave like a Windows Folder doesn't make sense to me.

It's not exactly about behaving like a Windows folder, it's about having a useful, predictable, well-thought-out behaviour based on the paradigm of items. File items in a Windows folder just happen to be the most well-known and most wide-spread implementation of items in a container with a fully developed keyboard access. If you can present another well-known reference implementation - please share.

Otoh, creating our own item behaviour which ignores users' behaviour expectations formed by the most well-known reference implementation is guaranteed to confuse users of windows with their decades of experience how items work in Windows Explorer which they use every day, especially wrt keyboard access.

Imho, from decades of UX design experience, it's typically much better to respond to an explicit user keyboard input in a safe and helpful way if possible, rather than not responding. Try to think of each recipient as a cubic box - why should deliberately placing some boxes on top of that (in the same room) fail or destroy the existing boxes?