Bug 920546 - [Messages] Short-term fixes for the recipient panel

https://bugzilla.mozilla.org/show_bug.cgi?id=920546

- Apply new "invalid recipient" indicator style
- Decouple searchContact from list display
- Create ThreadUI.listContact(...)
- Create ThreadUI.validateContact(...)
- Adds two level validation:
    - Is the entry questionable?
        - This kicks off a silent search for matching contacts
        - If there are one or more matches, use the first to create a Recipient
    - Is the entry invalid?
        - This state is reached if no contacts could be found
          for the typed value.
        - Prevents enableSend
        - Prevents "export" of recipient entry at Send
          (when mixed with multiple valid recipients)
- Refactor Utils.getContactDisplayInfo logic
- Adds tests for enableSend
- Adds tests for questionable Recipient detection.

Changes, post review:

> Bug 1:
>  - enter a bogus recipient, press enter to "accept" it
>  - press backspace => the cursor is correctly inside the contenteditable element, but it's still "red" and the keyboard is hiding

Fixed by adding CSS rules:
  [contenteditable=false].attention
  [contenteditable=true].attention

---

> Bug 2:
>  - with the recipient light workload, that has a "Adam L. Card" contact
>  - typing exactly "Adam L. Card" => no match
>  - typing "Adam Card" => match

Yep, this has always been true. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=860804

---

> Bug 3:
>  - add text in the composer
>  - add a bogus contact => the send button is enabled, should be disabled

Fixed by being more explicit in enableSend:

Set hasRecipients to true based on the following conditions:

 1. There is a valid recipients object
 2. One of the following is true:
     - The recipients object contains at least 1 valid recipient
       - OR -
     - There is >1 character typed and the value will not
       evaluate to a NaN

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>
Bug 920546 - [Messages] Short-term fixes for the recipient panel

https://bugzilla.mozilla.org/show_bug.cgi?id=920546

- Apply new "invalid recipient" indicator style
- Decouple searchContact from list display
- Create ThreadUI.listContact(...)
- Create ThreadUI.validateContact(...)
- Adds two level validation:
    - Is the entry questionable?
        - This kicks off a silent search for matching contacts
        - If there are one or more matches, use the first to create a Recipient
    - Is the entry invalid?
        - This state is reached if no contacts could be found
          for the typed value.
        - Prevents enableSend
        - Prevents "export" of recipient entry at Send
          (when mixed with multiple valid recipients)
- Refactor Utils.getContactDisplayInfo logic
- Adds tests for enableSend
- Adds tests for questionable Recipient detection.

Changes, post review:

> Bug 1:
>  - enter a bogus recipient, press enter to "accept" it
>  - press backspace => the cursor is correctly inside the contenteditable element, but it's still "red" and the keyboard is hiding

Fixed by adding CSS rules:
  [contenteditable=false].attention
  [contenteditable=true].attention

---

> Bug 2:
>  - with the recipient light workload, that has a "Adam L. Card" contact
>  - typing exactly "Adam L. Card" => no match
>  - typing "Adam Card" => match

Yep, this has always been true. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=860804

---

> Bug 3:
>  - add text in the composer
>  - add a bogus contact => the send button is enabled, should be disabled

Fixed by being more explicit in enableSend:

Set hasRecipients to true based on the following conditions:

 1. There is a valid recipients object
 2. One of the following is true:
     - The recipients object contains at least 1 valid recipient
       - OR -
     - There is >1 character typed and the value will not
       evaluate to a NaN

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>