Bug 1660691 Comment 14 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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

Thank you Alex for this awesome energy of implementing and trying new things fast!
I like the general design idea and it's looking pretty good.
I love that Ctrl/Shift+Arrow key combo continues to treat each pill including the new "Add to AB" button as a single entity, as well as Arrow-Left, and only Arrow-Right adds the extra focus stop for adding an unknown pill. That's pretty ingenious, feels quite natural, easy to discover, and intelligently adapting to different intentions as required. For lots of unknown pills, this will add lots of extra stops for Arrow-Right, but one could hold down the Arrow key a bit to move faster, or, for controlled and fast movements with single stops, use Ctrl+Arrow-Right and press Space on the target pill, apart from other shortcuts like END.

After testing this in action, there's quite a lot of devil in the detail.
Let's make this work better!

I have identified the following UX issues:

1) ux-consistency: Mouse click vs. Enter on pill's "Add to AB" button -> different focus
  - mouse: focus (automatically) moves to and remains on pill which was added to AB (that feels right)
  - Enter: focus jumps to address input, context lost, no ux-feedback to check for success. What if I want to add several nearby addresses in a row via keyboard? The focus jump will make that very cumbersome (curse Thunderbird!)
     (Btw, the focus jump is also wrong for editing a pill, bug on record iirc).
2) Space bar on focused "Add to AB" button selects pill instead
3) Deleting the only contact with a given email address from contacts sidebar (CSB) does not update recipient pill(s) to show "not in AB" button if applicable (need to check for every deletion from AB and update all applicable pills in all open composition windows)
4) Creating a new contact in AB which has one of the recipient email addresses previously not yet known in AB does not update status of affected pills to remove the Add-to-AB buttons
5) For duplicate recipient addresses in addressing area, adding one does not mark the duplicate pills as known. Worse, as the duplicate pill still has the add button, it can actually be added as a duplicate card into AB. Recipe for chaos and confusion!
6) Have search word "John" in contacts sidebar (All ABs), click on Add-to-AB button of a pill "Peter": new contact "Peter" shows up in CSB although it doesn't match the searchword, "John"
---
7) Maybe clicking the button could have some sort of visual feedback effect, on the button, and/or afterwards? Maybe turn button into green checkmark for 1 second before hiding it?
8) Would be nice to have a context menu entry: Add to AB - oh, is that part of the other bug?
9) Imo, the hover effect on Add to AB button is too subtle, both for selected and unselected pills.
10) I would sort of wish for this to work for multiple selected pills (selection should stay - preventDefault?), but we'd have to avoid ambiguities whether only the clicked pill or all selected pills get added. Maybe if for multiple selection, all the Add-to-AB buttons of all selected pills could be highlighted on hover of a single selected pill, that would work to indicate the action scope.

::: mail/base/content/mailWidgets.js
@@ +1984,5 @@
> +      addressBook.addCard(card);
> +
> +      this.pillButton.classList.remove("updating");
> +      this.updatePillStatus();
> +      this.rowInput.focus();

Not helpful.

::: mail/base/content/msgHdrView.js
@@ +1547,1 @@
>            aDocumentNode.cardDetails &&

Could the first two conditions be rewritten as follows using [Optional chaining operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)?
`aDocumentNode?.cardDetails &&`

::: mail/components/compose/content/MsgComposeCommands.js
@@ -7294,5 @@
>      [identityElement.selectedItem.value]
>    );
>  }
>  
> -function setupAutocompleteInput(input, highlightNonMatches) {

I'm not sure if we should remove highlightNonMatches parameter and pref. Security-sensitive users might still want to be alerted as early as possible about addresses not found in their AB. What if we just flip the pref to false by default?

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +910,5 @@
>    document.getElementById("recipientsContainer").removeSelectedPills(pill);
>  }
>  
>  /**
> + * Handle the disabling of context menu items according to the types and amount

count instead of amount?

::: mail/locales/en-US/messenger/messengercompose/messengercompose.ftl
@@ +25,5 @@
>  
> +#   $email (String) - the email address
> +pill-tooltip-invalid = { $email } is not a valid e-mail address
> +
> +pill-tooltip-add-address-book = Add to Address Book

If we know to which AB we're adding, should we say that in the tooltip? (not sure)

Add to Personal Address Book?

::: mail/themes/shared/mail/messengercompose.css
@@ +773,5 @@
> +  color: #fff;
> +  background-color: #d70022;
> +  background-image: url("chrome://global/skin/icons/warning.svg");
> +  background-repeat: no-repeat;
> +  background-position: calc(100% - 3px);

Brilliant!

@@ +787,5 @@
>  }
>  
>  .address-pill.error:hover:not(.editing),
> +.address-pill.error:focus:not(.editing),
> +#MsgHeadersToolbar[brighttext] .address-pill.error:hover:not(.editing)

Should this keep the trailing comma?

::: mailnews/mailnews.js
@@ -665,5 @@
>  pref("mailnews.traits.lastIndex", 1000);
>  
> -// Address entry will highlight input that doesn't match anything in the
> -// address books.
> -pref("mail.autoComplete.highlightNonMatches", true);

I would probably keep this pref but default to false.
Review of attachment 9192774 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you Alex for this awesome energy of implementing and trying new things fast!
I like the general design idea and it's looking pretty good.
I love that Ctrl/Shift+Arrow key combo continues to treat each pill including the new "Add to AB" button as a single entity, as well as Arrow-Left, and only Arrow-Right reaches the extra focus stop for adding an unknown pill. That's pretty ingenious, feels quite natural, easy to discover, and intelligently adapting to different intentions as required. For lots of unknown pills, this will add lots of extra stops for Arrow-Right, but one could hold down the Arrow key a bit to move faster, or, for controlled and fast movements with single stops, use Ctrl+Arrow-Right and press Space on the target pill, apart from other shortcuts like END.

After testing this in action, there's quite a lot of devil in the detail.
Let's make this work better!

I have identified the following UX issues:

1) ux-consistency: Mouse click vs. Enter on pill's "Add to AB" button -> different focus
  - mouse: focus (automatically) moves to and remains on pill which was added to AB (that feels right)
  - Enter: focus jumps to address input, context lost, no ux-feedback to check for success. What if I want to add several nearby addresses in a row via keyboard? The focus jump will make that very cumbersome (curse Thunderbird!)
     (Btw, the focus jump is also wrong for editing a pill, bug on record iirc).
2) Space bar on focused "Add to AB" button selects pill instead
3) Deleting the only contact with a given email address from contacts sidebar (CSB) does not update recipient pill(s) to show "not in AB" button if applicable (need to check for every deletion from AB and update all applicable pills in all open composition windows)
4) Creating a new contact in AB which has one of the recipient email addresses previously not yet known in AB does not update status of affected pills to remove the Add-to-AB buttons
5) For duplicate recipient addresses in addressing area, adding one does not mark the duplicate pills as known. Worse, as the duplicate pill still has the add button, it can actually be added as a duplicate card into AB. Recipe for chaos and confusion!
6) Have search word "John" in contacts sidebar (All ABs), click on Add-to-AB button of a pill "Peter": new contact "Peter" shows up in CSB although it doesn't match the searchword, "John"
---
7) Maybe clicking the button could have some sort of visual feedback effect, on the button, and/or afterwards? Maybe turn button into green checkmark for 1 second before hiding it?
8) Would be nice to have a context menu entry: Add to AB - oh, is that part of the other bug?
9) Imo, the hover effect on Add to AB button is too subtle, both for selected and unselected pills.
10) I would sort of wish for this to work for multiple selected pills (selection should stay - preventDefault?), but we'd have to avoid ambiguities whether only the clicked pill or all selected pills get added. Maybe if for multiple selection, all the Add-to-AB buttons of all selected pills could be highlighted on hover of a single selected pill, that would work to indicate the action scope.

::: mail/base/content/mailWidgets.js
@@ +1984,5 @@
> +      addressBook.addCard(card);
> +
> +      this.pillButton.classList.remove("updating");
> +      this.updatePillStatus();
> +      this.rowInput.focus();

Not helpful.

::: mail/base/content/msgHdrView.js
@@ +1547,1 @@
>            aDocumentNode.cardDetails &&

Could the first two conditions be rewritten as follows using [Optional chaining operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)?
`aDocumentNode?.cardDetails &&`

::: mail/components/compose/content/MsgComposeCommands.js
@@ -7294,5 @@
>      [identityElement.selectedItem.value]
>    );
>  }
>  
> -function setupAutocompleteInput(input, highlightNonMatches) {

I'm not sure if we should remove highlightNonMatches parameter and pref. Security-sensitive users might still want to be alerted as early as possible about addresses not found in their AB. What if we just flip the pref to false by default?

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +910,5 @@
>    document.getElementById("recipientsContainer").removeSelectedPills(pill);
>  }
>  
>  /**
> + * Handle the disabling of context menu items according to the types and amount

count instead of amount?

::: mail/locales/en-US/messenger/messengercompose/messengercompose.ftl
@@ +25,5 @@
>  
> +#   $email (String) - the email address
> +pill-tooltip-invalid = { $email } is not a valid e-mail address
> +
> +pill-tooltip-add-address-book = Add to Address Book

If we know to which AB we're adding, should we say that in the tooltip? (not sure)

Add to Personal Address Book?

::: mail/themes/shared/mail/messengercompose.css
@@ +773,5 @@
> +  color: #fff;
> +  background-color: #d70022;
> +  background-image: url("chrome://global/skin/icons/warning.svg");
> +  background-repeat: no-repeat;
> +  background-position: calc(100% - 3px);

Brilliant!

@@ +787,5 @@
>  }
>  
>  .address-pill.error:hover:not(.editing),
> +.address-pill.error:focus:not(.editing),
> +#MsgHeadersToolbar[brighttext] .address-pill.error:hover:not(.editing)

Should this keep the trailing comma?

::: mailnews/mailnews.js
@@ -665,5 @@
>  pref("mailnews.traits.lastIndex", 1000);
>  
> -// Address entry will highlight input that doesn't match anything in the
> -// address books.
> -pref("mail.autoComplete.highlightNonMatches", true);

I would probably keep this pref but default to false.
Review of attachment 9192774 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you Alex for this awesome energy of implementing and trying new things fast!
I like the general design idea and it's looking pretty good.
I love that Ctrl/Shift+Arrow key combo continues to treat each pill including the new "Add to AB" button as a single entity, as well as Arrow-Left, and only Arrow-Right reaches the extra focus stop for adding an unknown pill. That's pretty ingenious, feels quite natural, easy to discover, and intelligently adapting to different intentions as required. For lots of unknown pills, this will add lots of extra stops for Arrow-Right, but one could hold down the Arrow key a bit to move faster, or, for controlled and fast movements with single stops, use Ctrl+Arrow-Right and press Space on the target pill, apart from other shortcuts like END.

After testing this in action, there's quite a lot of devil in the detail.
Let's make this work better!

I have identified the following UX issues:

1) ux-consistency: Mouse click vs. Enter on pill's "Add to AB" button -> different focus
  - mouse: focus (automatically) moves to and remains on pill which was added to AB (that feels right)
  - Enter: focus jumps to address input, context lost, no ux-feedback to check for success. What if I want to add several nearby addresses in a row via keyboard? The focus jump will make that very cumbersome (curse Thunderbird!)
     (Btw, the focus jump is also wrong for editing a pill, bug on record iirc).
2) Space bar on focused "Add to AB" button selects pill instead
3) Deleting the only contact with a given email address from contacts sidebar (CSB) does not update recipient pill(s) to show "Add to AB" button if applicable (need to check for every deletion from AB and update all applicable pills in all open composition windows)
4) Creating a new contact in AB which has one of the recipient email addresses previously not yet known in AB does not update status of affected pills to remove the Add-to-AB buttons
5) For duplicate recipient addresses in addressing area, adding one does not mark the duplicate pills as known. Worse, as the duplicate pill still has the add button, it can actually be added as a duplicate card into AB. Recipe for chaos and confusion!
6) Have search word "John" in contacts sidebar (All ABs), click on Add-to-AB button of a pill "Peter": new contact "Peter" shows up in CSB although it doesn't match the searchword, "John"
---
7) Maybe clicking the button could have some sort of visual feedback effect, on the button, and/or afterwards? Maybe turn button into green checkmark for 1 second before hiding it?
8) Would be nice to have a context menu entry: Add to AB - oh, is that part of the other bug?
9) Imo, the hover effect on Add to AB button is too subtle, both for selected and unselected pills.
10) I would sort of wish for this to work for multiple selected pills (selection should stay - preventDefault?), but we'd have to avoid ambiguities whether only the clicked pill or all selected pills get added. Maybe if for multiple selection, all the Add-to-AB buttons of all selected pills could be highlighted on hover of a single selected pill, that would work to indicate the action scope.

::: mail/base/content/mailWidgets.js
@@ +1984,5 @@
> +      addressBook.addCard(card);
> +
> +      this.pillButton.classList.remove("updating");
> +      this.updatePillStatus();
> +      this.rowInput.focus();

Not helpful.

::: mail/base/content/msgHdrView.js
@@ +1547,1 @@
>            aDocumentNode.cardDetails &&

Could the first two conditions be rewritten as follows using [Optional chaining operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)?
`aDocumentNode?.cardDetails &&`

::: mail/components/compose/content/MsgComposeCommands.js
@@ -7294,5 @@
>      [identityElement.selectedItem.value]
>    );
>  }
>  
> -function setupAutocompleteInput(input, highlightNonMatches) {

I'm not sure if we should remove highlightNonMatches parameter and pref. Security-sensitive users might still want to be alerted as early as possible about addresses not found in their AB. What if we just flip the pref to false by default?

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +910,5 @@
>    document.getElementById("recipientsContainer").removeSelectedPills(pill);
>  }
>  
>  /**
> + * Handle the disabling of context menu items according to the types and amount

count instead of amount?

::: mail/locales/en-US/messenger/messengercompose/messengercompose.ftl
@@ +25,5 @@
>  
> +#   $email (String) - the email address
> +pill-tooltip-invalid = { $email } is not a valid e-mail address
> +
> +pill-tooltip-add-address-book = Add to Address Book

If we know to which AB we're adding, should we say that in the tooltip? (not sure)

Add to Personal Address Book?

::: mail/themes/shared/mail/messengercompose.css
@@ +773,5 @@
> +  color: #fff;
> +  background-color: #d70022;
> +  background-image: url("chrome://global/skin/icons/warning.svg");
> +  background-repeat: no-repeat;
> +  background-position: calc(100% - 3px);

Brilliant!

@@ +787,5 @@
>  }
>  
>  .address-pill.error:hover:not(.editing),
> +.address-pill.error:focus:not(.editing),
> +#MsgHeadersToolbar[brighttext] .address-pill.error:hover:not(.editing)

Should this keep the trailing comma?

::: mailnews/mailnews.js
@@ -665,5 @@
>  pref("mailnews.traits.lastIndex", 1000);
>  
> -// Address entry will highlight input that doesn't match anything in the
> -// address books.
> -pref("mail.autoComplete.highlightNonMatches", true);

I would probably keep this pref but default to false.
Review of attachment 9192774 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you Alex for this awesome energy of implementing and trying new things fast!
I like the general design idea and it's looking pretty good.
I love that Ctrl/Shift+Arrow key combo continues to treat each pill including the new "Add to AB" button as a single entity, as well as Arrow-Left, and only Arrow-Right reaches the extra focus stop for adding an unknown pill. That's pretty ingenious, feels quite natural, easy to discover, and intelligently adapting to different intentions as required. For lots of unknown pills, this will add lots of extra stops for Arrow-Right, but one could hold down the Arrow key a bit to move faster, or, for controlled and fast movements with single stops, use Ctrl+Arrow-Right and press Space on the target pill, apart from other shortcuts like END.

After testing this in action, there's quite a lot of devil in the detail.
Let's make this work better!

I have identified the following UX issues:

1) ux-consistency: Mouse click vs. Enter on pill's "Add to AB" button -> different focus
  - mouse: focus (automatically) moves to and remains on pill which was added to AB (that feels right)
  - Enter: focus jumps to address input, context lost, no ux-feedback to check for success. What if I want to add several nearby addresses in a row via keyboard? The focus jump will make that very cumbersome (curse Thunderbird!)
     (Btw, the focus jump is also wrong for editing a pill, bug on record iirc).
2) Space bar on focused "Add to AB" button selects pill instead
3) Deleting the only contact with a given email address from contacts sidebar (CSB) does not update recipient pill(s) to show "Add to AB" button if applicable (need to check for every deletion from AB and update all applicable pills in all open composition windows)
4) Creating a new contact in AB which has one of the recipient email addresses previously not yet known in AB does not update status of affected pills to remove the Add-to-AB buttons
5) For duplicate recipient addresses in addressing area, adding one to AB does not mark the duplicate pills as known. Worse, as the duplicate pill still has the add button, it can actually be added as a duplicate card into AB. Recipe for chaos and confusion!
6) Have search word "John" in contacts sidebar (All ABs), click on Add-to-AB button of a pill "Peter": new contact "Peter" shows up in CSB although it doesn't match the searchword, "John"
---
7) Maybe clicking the button could have some sort of visual feedback effect, on the button, and/or afterwards? Maybe turn button into green checkmark for 1 second before hiding it?
8) Would be nice to have a context menu entry: Add to AB - oh, is that part of the other bug?
9) Imo, the hover effect on Add to AB button is too subtle, both for selected and unselected pills.
10) I would sort of wish for this to work for multiple selected pills (selection should stay - preventDefault?), but we'd have to avoid ambiguities whether only the clicked pill or all selected pills get added. Maybe if for multiple selection, all the Add-to-AB buttons of all selected pills could be highlighted on hover of a single selected pill, that would work to indicate the action scope.

::: mail/base/content/mailWidgets.js
@@ +1984,5 @@
> +      addressBook.addCard(card);
> +
> +      this.pillButton.classList.remove("updating");
> +      this.updatePillStatus();
> +      this.rowInput.focus();

Not helpful.

::: mail/base/content/msgHdrView.js
@@ +1547,1 @@
>            aDocumentNode.cardDetails &&

Could the first two conditions be rewritten as follows using [Optional chaining operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)?
`aDocumentNode?.cardDetails &&`

::: mail/components/compose/content/MsgComposeCommands.js
@@ -7294,5 @@
>      [identityElement.selectedItem.value]
>    );
>  }
>  
> -function setupAutocompleteInput(input, highlightNonMatches) {

I'm not sure if we should remove highlightNonMatches parameter and pref. Security-sensitive users might still want to be alerted as early as possible about addresses not found in their AB. What if we just flip the pref to false by default?

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +910,5 @@
>    document.getElementById("recipientsContainer").removeSelectedPills(pill);
>  }
>  
>  /**
> + * Handle the disabling of context menu items according to the types and amount

count instead of amount?

::: mail/locales/en-US/messenger/messengercompose/messengercompose.ftl
@@ +25,5 @@
>  
> +#   $email (String) - the email address
> +pill-tooltip-invalid = { $email } is not a valid e-mail address
> +
> +pill-tooltip-add-address-book = Add to Address Book

If we know to which AB we're adding, should we say that in the tooltip? (not sure)

Add to Personal Address Book?

::: mail/themes/shared/mail/messengercompose.css
@@ +773,5 @@
> +  color: #fff;
> +  background-color: #d70022;
> +  background-image: url("chrome://global/skin/icons/warning.svg");
> +  background-repeat: no-repeat;
> +  background-position: calc(100% - 3px);

Brilliant!

@@ +787,5 @@
>  }
>  
>  .address-pill.error:hover:not(.editing),
> +.address-pill.error:focus:not(.editing),
> +#MsgHeadersToolbar[brighttext] .address-pill.error:hover:not(.editing)

Should this keep the trailing comma?

::: mailnews/mailnews.js
@@ -665,5 @@
>  pref("mailnews.traits.lastIndex", 1000);
>  
> -// Address entry will highlight input that doesn't match anything in the
> -// address books.
> -pref("mail.autoComplete.highlightNonMatches", true);

I would probably keep this pref but default to false.
Review of attachment 9192774 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you Alex for this awesome energy of implementing and trying new things fast!
I like the general design idea and it's looking pretty good.
I love that Ctrl/Shift+Arrow key combo continues to treat each pill as a single entity regardless of the new "Add to AB" button, as well as Arrow-Left, and only Arrow-Right reaches the extra focus stop for adding an unknown pill. That's pretty ingenious, feels quite natural, easy to discover, and intelligently adapting to different intentions as required. For lots of unknown pills, this will add lots of extra stops for Arrow-Right, but one could hold down the Arrow key a bit to move faster, or, for controlled and fast movements with single stops, use Ctrl+Arrow-Right and press Space on the target pill, apart from other shortcuts like END.

After testing this in action, there's quite a lot of devil in the detail.
Let's make this work better!

I have identified the following UX issues:

1) ux-consistency: Mouse click vs. Enter on pill's "Add to AB" button -> different focus
  - mouse: focus (automatically) moves to and remains on pill which was added to AB (that feels right)
  - Enter: focus jumps to address input, context lost, no ux-feedback to check for success. What if I want to add several nearby addresses in a row via keyboard? The focus jump will make that very cumbersome (curse Thunderbird!)
     (Btw, the focus jump is also wrong for editing a pill, bug on record iirc).
2) Space bar on focused "Add to AB" button selects pill instead
3) Deleting the only contact with a given email address from contacts sidebar (CSB) does not update recipient pill(s) to show "Add to AB" button if applicable (need to check for every deletion from AB and update all applicable pills in all open composition windows)
4) Creating a new contact in AB which has one of the recipient email addresses previously not yet known in AB does not update status of affected pills to remove the Add-to-AB buttons
5) For duplicate recipient addresses in addressing area, adding one to AB does not mark the duplicate pills as known. Worse, as the duplicate pill still has the add button, it can actually be added as a duplicate card into AB. Recipe for chaos and confusion!
6) Have search word "John" in contacts sidebar (All ABs), click on Add-to-AB button of a pill "Peter": new contact "Peter" shows up in CSB although it doesn't match the searchword, "John"
---
7) Maybe clicking the button could have some sort of visual feedback effect, on the button, and/or afterwards? Maybe turn button into green checkmark for 1 second before hiding it?
8) Would be nice to have a context menu entry: Add to AB - oh, is that part of the other bug?
9) Imo, the hover effect on Add to AB button is too subtle, both for selected and unselected pills.
10) I would sort of wish for this to work for multiple selected pills (selection should stay - preventDefault?), but we'd have to avoid ambiguities whether only the clicked pill or all selected pills get added. Maybe if for multiple selection, all the Add-to-AB buttons of all selected pills could be highlighted on hover of a single selected pill, that would work to indicate the action scope.

::: mail/base/content/mailWidgets.js
@@ +1984,5 @@
> +      addressBook.addCard(card);
> +
> +      this.pillButton.classList.remove("updating");
> +      this.updatePillStatus();
> +      this.rowInput.focus();

Not helpful.

::: mail/base/content/msgHdrView.js
@@ +1547,1 @@
>            aDocumentNode.cardDetails &&

Could the first two conditions be rewritten as follows using [Optional chaining operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)?
`aDocumentNode?.cardDetails &&`

::: mail/components/compose/content/MsgComposeCommands.js
@@ -7294,5 @@
>      [identityElement.selectedItem.value]
>    );
>  }
>  
> -function setupAutocompleteInput(input, highlightNonMatches) {

I'm not sure if we should remove highlightNonMatches parameter and pref. Security-sensitive users might still want to be alerted as early as possible about addresses not found in their AB. What if we just flip the pref to false by default?

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +910,5 @@
>    document.getElementById("recipientsContainer").removeSelectedPills(pill);
>  }
>  
>  /**
> + * Handle the disabling of context menu items according to the types and amount

count instead of amount?

::: mail/locales/en-US/messenger/messengercompose/messengercompose.ftl
@@ +25,5 @@
>  
> +#   $email (String) - the email address
> +pill-tooltip-invalid = { $email } is not a valid e-mail address
> +
> +pill-tooltip-add-address-book = Add to Address Book

If we know to which AB we're adding, should we say that in the tooltip? (not sure)

Add to Personal Address Book?

::: mail/themes/shared/mail/messengercompose.css
@@ +773,5 @@
> +  color: #fff;
> +  background-color: #d70022;
> +  background-image: url("chrome://global/skin/icons/warning.svg");
> +  background-repeat: no-repeat;
> +  background-position: calc(100% - 3px);

Brilliant!

@@ +787,5 @@
>  }
>  
>  .address-pill.error:hover:not(.editing),
> +.address-pill.error:focus:not(.editing),
> +#MsgHeadersToolbar[brighttext] .address-pill.error:hover:not(.editing)

Should this keep the trailing comma?

::: mailnews/mailnews.js
@@ -665,5 @@
>  pref("mailnews.traits.lastIndex", 1000);
>  
> -// Address entry will highlight input that doesn't match anything in the
> -// address books.
> -pref("mail.autoComplete.highlightNonMatches", true);

I would probably keep this pref but default to false.

Back to Bug 1660691 Comment 14