Open Bug 1602461 Opened 8 months ago Updated 2 months ago

Allow pasting pills or plain text when other pills of target field are selected

Categories

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

enhancement

Tracking

(Not tracked)

People

(Reporter: bugzilla2007, Unassigned)

References

()

Details

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

STR

  1. To-field, select to-pill
  2. Cut
  3. CC-field, select cc-pill
  4. Paste (maybe expecting to replace cc-pill, but reasons don't matter, users will find them)

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

Summary: Allow pasting pills when other pills are selected → Allow pasting pills when other pills of target field are selected

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?

(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.

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.

Summary: Allow pasting pills when other pills of target field are selected → Allow pasting pills or plain text when other pills of target field are selected
See Also: → 1602456

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.

Priority: -- → P3

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

Severity: minor → N/A
Component: Composition → Message Compose Window
Product: MailNews Core → Thunderbird
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.