Whitespace-only values in composition's recipient inputs are invalid, useless, and undesired. They are invisible and hence cunningly prevent keyboard navigation into adjacent pills. Instead of adding more hooks and checks to work around or fix them later in unrelated events, we can just prevent them from occuring. **STR** 1) compose, type an address followed by comma and space into any recipient input: |foo@bar.com, | (with an initial intention of adding another address) 2) note an error in the first address, should be "fox@bar.com" 3) cursor left to select `foo@bar.com` pill for editing **Actual result** - comma auto-creates pill (ok), invisible space (░) remains in input box: `foo@bar.com` ░| - pressing cursor left to select first pill for editing *fails* (due to the invisible space, i.e. without any obvious reason): `foo@bar.com` |░ - confusingly, we sanitize at some random time after the fact, but only for certain scenarios (Enter) **Expected result** - Noting that... - an email address cannot begin with spaces unless quoted - nobody starts an email address with spaces by putting spaces first - there are several other ways to remain with spaces-only in the input - there are many ways to unfocus an input (enter, tab, click elsewhere) - whitespace-only in the input is neither useful nor valid unless with quotes or other characters - ... we should just prevent whitespace-only values from occuring, which is much easier, safer, and better ux - I.e. for the STR above, eliminate the space after the comma as soon as the first pill is created, and allow immediate cursor-left navigation to correct the first pill.
Bug 1629364 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Whitespace-only values in composition's recipient inputs are invalid, useless, and undesired. They are invisible and hence cunningly prevent keyboard navigation into adjacent pills. Instead of adding more hooks and checks to work around or fix them later in unrelated events, we can just prevent them from occuring. **STR** 1) compose, type an address followed by comma and space into any recipient input: |foo@bar.com, | (with an initial intention of adding another address) 2) note an error in the first address, should be "fox@bar.com" 3) cursor left (repeatedly) to select `foo@bar.com` pill for editing **Actual result** - comma auto-creates pill (ok), invisible space (░) remains in input box: `foo@bar.com` ░| - pressing cursor left to select first pill for editing *fails* (due to the invisible space, i.e. without any obvious reason): `foo@bar.com` |░ - confusingly, we sanitize at some random time after the fact, but only for certain scenarios (Enter) **Expected result** - Noting that... - an email address cannot begin with spaces unless quoted - nobody starts an email address with spaces by putting spaces first - there are several other ways to remain with spaces-only in the input - there are many ways to unfocus an input (enter, tab, click elsewhere) - whitespace-only in the input is neither useful nor valid unless with quotes or other characters - ... we should just prevent whitespace-only values from occuring, which is much easier, safer, and better ux - I.e. for the STR above, eliminate the space after the comma as soon as the first pill is created, and allow immediate cursor-left navigation to correct the first pill.
Whitespace-only values in composition's recipient inputs are invalid, useless, and undesired. They are invisible and hence cunningly prevent keyboard navigation into adjacent pills. Instead of adding more hooks and checks to work around or fix them later in unrelated events, we can just prevent them from occuring. **STR** 1) compose, type an address followed by comma and space into any recipient input: |foo@bar.com, | (with an initial intention of adding another address) 2) note an error in the first address, should be "fox@bar.com" 3) cursor left (repeatedly) to select `foo@bar.com` pill for editing **Actual result** - comma auto-creates pill (ok), invisible space (░) remains in input box, followed by cursor: `foo@bar.com` ░| - pressing cursor left to select first pill for editing *fails* (due to the invisible space, i.e. without any obvious reason): `foo@bar.com` |░ - confusingly, we sanitize at some random time after the fact, but only for certain scenarios (Enter) **Expected result** - Noting that... - an email address cannot begin with spaces unless quoted - nobody starts an email address with spaces by putting spaces first - there are several other ways to remain with spaces-only in the input - there are many ways to unfocus an input (enter, tab, click elsewhere) - whitespace-only in the input is neither useful nor valid unless with quotes or other characters - ... we should just prevent whitespace-only values from occuring, which is much easier, safer, and better ux - I.e. for the STR above, eliminate the space after the comma as soon as the first pill is created, and allow immediate cursor-left navigation to correct the first pill.
Whitespace-only values in composition's recipient inputs are invalid, useless, and undesired. They occur easily especially when entering comma-separated email addresses. They are invisible and hence cunningly prevent keyboard navigation into adjacent pills. Instead of adding more hooks and checks to work around or fix them later in unrelated events, we can just prevent them from occuring. **STR** 1) compose, type an address followed by comma and space into any recipient input: |foo@bar.com, | (with an initial intention of adding another address) 2) note an error in the first address, should be "fox@bar.com" 3) cursor left (repeatedly) to select `foo@bar.com` pill for editing **Actual result** - comma auto-creates pill (ok), invisible space (░) remains in input box, followed by cursor: `foo@bar.com` ░| - pressing cursor left to select first pill for editing *fails* (due to the invisible space, i.e. without any obvious reason): `foo@bar.com` |░ - confusingly, we sanitize at some random time after the fact, but only for certain scenarios (Enter) **Expected result** - Noting that... - an email address cannot begin with spaces unless quoted - nobody starts an email address with spaces by putting spaces first - there are several other ways to remain with spaces-only in the input - there are many ways to unfocus an input (enter, tab, click elsewhere) - whitespace-only in the input is neither useful nor valid unless with quotes or other characters - ... we should just prevent whitespace-only values from occuring, which is much easier, safer, and better ux - I.e. for the STR above, eliminate the space after the comma as soon as the first pill is created, and allow immediate cursor-left navigation to correct the first pill.