Closed Bug 1627451 Opened 2 years ago Closed 2 years ago

Edit recipient pill: Making short email address longer does not adjust pill size, pushes address out of pill, cursor outside pill


(Thunderbird :: Message Compose Window, defect, P1)



(Not tracked)

Thunderbird 77.0


(Reporter: thomas8, Assigned: aleca)



(Keywords: regression)


(3 files)

Editing an existing pill leads to all sorts of weird behaviour as the pill size does not auto-adjust to longer email addresses. It definitely should.


  1. compose to: [sic, length matters], press Enter to create pill
    nextpill <>, Enter
  2. edit 1st pill (short address, so pill border expands by about 7 characters to predefined default length)
  3. add display name and opening bracket before plain email address ( | represents cursor):
    John Darlington <|
  4. while still editing, press END key now and add closing bracket

Actual Result

  • for short addresses, pill frame initially expands to predefined default length; for addresses longer than default length, it does not expand: somewhat inconsistent.
  • Default pill length is way too short, can't even fit a shorter common address like John Johnson <>
  • As soon as the entire address exceeds pill default length, it is pushed outside the pill frame to the right side (and sometimes to the left), and even overlaps the next pill: odd (see screenshot 1).
  • Worse, when you move cursor to the END of pill text (e.g. to change domain name), you'll end up typing outside the pill frame: more than odd! So that part is like an extreme variant of bug 1609958.

Expected Result

  • If we need a default length for pills at all, it must be longer to fit at regular addresses like John Johnson <>
  • Need some way of ensuring that during pill editing, the full email address is always inside the pill frame, i.e. the pill must dynamically adjust in size somehow

Possible behaviours

  1. initial expansion: expand pill size when entering edit mode (always, not only for short addresses), and probably expand more (say 15em)
  2. initial close fit: alternatively, do not expand pill size when entering edit mode; start editing in "close fit pill", then instead, only do 3)
  3. gradual excess expansion: when user input gets longer than pill frame, dynamically expand pill size character by character as user types along, which will slow push other pills along (just like it would for any subsequent text in any input, nothing strange here)
  4. stepwise excess expansion: Alternatively, whenever user input get's longer than pill frame (triggered early with some blank-space offset), expand pill size by a fixed measure (say 15em).

I'm not sure which behaviour would feel most convenient and natural, but the current behaviour is odd and wrong.
I do like that we initially expand the pill, so I think 1) is good for starters.
After that, when input reaches the pill limit again (with some early-trigger offset of at least 5em permanent blank space on the right), our choice is between 3) gradual excess expansion and 4) stepwise excess expansion. 3) feels natural, but it keeps pushing pills around as you type. Maybe 4) stepwise expansion is good. Let's not be too stingy, adding 15 em blank space is minimum imo.

For the avoidance of doubt, any email address text disappearing to either side, even temporarily while editing, and even if this was rectified to at least keep the cursor always within the pill frame, is odd and counter-productive imo. Users really want to see the full address whilst editing, always, that's how we double-check to avoid errors. Dancing around with cursor to verify the address before entering, or having to double-check after pill creation (where focus jumps away to row input), are both non-practical.

See Also: → 1609958

This is most likely a regression due to some changes that landed on m-c related to input fields.
We already fixed a couple of those in the past week, and I'm not surprised more issues are popping out.
I'll deal with that.

Assignee: nobody → alessandro
Keywords: regression
No longer regressed by: tb-pills
Priority: -- → P1

It seems that the input field doesn't account anymore for the pill padding, that's why the text was overflowing and the cursor wasn't visible when editing a long pill.
I'm manually adding the padding inline to account for that, as I can't seem to get the computedStyle of the element. That value is consistent across OSs, so it should be fine, but let me know if you have a better approach to suggest.

Regarding your suggestions Thomas, I don't think we should touch this section.
Pills follow the size of the address typed. If a user edits a pill with a short address, the pill expands to accommodate the default min-width of the input field.
If the user types a longer address in a shorter pill, the pill will resize upon saving. Growing pills to fit an arbitrary size is not a good approach.

Attachment #9138614 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9138614 [details] [diff] [review]

Review of attachment 9138614 [details] [diff] [review]:

LGTM, r=mkmelin
Sorry for the delay.
Attachment #9138614 - Flags: review?(mkmelin+mozilla) → review+
Target Milestone: --- → Thunderbird 77.0

Pushed by
Fix recipient pill not respecting the child input field size. r=mkmelin

Closed: 2 years ago
Resolution: --- → FIXED
Component: Composition → Message Compose Window
Product: MailNews Core → Thunderbird
You need to log in before you can comment on or make changes to this bug.