Closed Bug 1855276 Opened 2 years ago Closed 7 months ago

Addressing pill too short: Recipient's domain suffix sometimes gets cut off (or otherwise shortened by inserting an ellipsis) in the To field on 1st attempt at replying to a message

Categories

(Thunderbird :: Message Compose Window, defect)

Thunderbird 115
defect

Tracking

(thunderbird_esr128 fixed, thunderbird134 affected)

RESOLVED FIXED
135 Branch
Tracking Status
thunderbird_esr128 --- fixed
thunderbird134 --- affected

People

(Reporter: thee.chicago.wolf, Assigned: Paenglab)

References

Details

(Keywords: regression, triaged)

Attachments

(5 files)

I have observed this issue once in a while but here's my generic STR using 115.2.3.

  1. You receive a message from a known / unknown sender and click the Reply button

Actual Results:

  1. In the To field, the sender's email address occasionally cuts off the domain suffix (see image)

Expected Results:

  1. In the To field, the sender's email address should not cut off the domain suffix.

When I notice it, it only seems to happen the 1st time I click Reply to a sender. If I cancel or close the compser window and then click Reply to the sender a 2nd time, I cannot repro the problem.

I observed this one 115.3.0 this morning. Domain suffix wasn't cut off but the closing greater than symbol (>) got a bit cut off. This is only happening for me on newly arrived---and, it seems, unread--- messages and a 1st reply to the new message. Subsequently reading it / replying to it, or even marking as unread and re-replying to it won't seem to trigger the issue.

Duplicate of this bug: 1856314
Duplicate of this bug: 1866975
Severity: -- → S3
Keywords: triaged
OS: Windows 10 → All
Hardware: x86_64 → All
Duplicate of this bug: 1892874
Duplicate of this bug: 1897917
Duplicate of this bug: 1938029

This bug can be found easier with the word "pill" in the summary.

Summary: Recipient's domain suffix sometimes gets cut off or is not fully visible in the To field on 1st attempt at replying to a message → Recipient's domain suffix sometimes gets cut off or is not fully visible in the To field on 1st attempt at replying to a message (Addressing pill to short / cut off)

The reporter in bug 1938029 states that this happens for addresses not in any address book. I can reproduce with a reply to a message where the sender is not in the address book. It happens for the first reply in a new session (ideal to find the regression with mozregression).

Alice, can you do some investigation for us, please. STR:
Start TB. Reply to a message where the sender is not in the address book. Preferably a sender with a "longish" address.
Check whether the sender is displayed fully in the To: field.

Looks like the bug has morphed somehow: In the beginning, the pills were cut off, now they are made shorter by inserting an ellipsis.

Flags: needinfo?(alice0775)
Summary: Recipient's domain suffix sometimes gets cut off or is not fully visible in the To field on 1st attempt at replying to a message (Addressing pill to short / cut off) → Addressing pill to short: Recipient's domain suffix sometimes gets cut off (or otherwise shortened by inserting an ellipsis) in the To field on 1st attempt at replying to a message

Emilio, do you see this? The bug is somewhat "evanescent", I just had it happen, and as soon as I started the dev tools, the windows was redrawn and the pill was no longer shortened. Hard to catch, unless maybe you can use rr.

Flags: needinfo?(emilio)
Summary: Addressing pill to short: Recipient's domain suffix sometimes gets cut off (or otherwise shortened by inserting an ellipsis) in the To field on 1st attempt at replying to a message → Addressing pill too short: Recipient's domain suffix sometimes gets cut off (or otherwise shortened by inserting an ellipsis) in the To field on 1st attempt at replying to a message

I can't to reproduce it.
It seems to be working as expected in Daily135.0a1, TB115.18, TB123.0.3 Windows 11.

Flags: needinfo?(alice0775)

Thanks for testing, Alice. Not easy to reproduce, but here is fails every time.

Apparently the shortening was replaced by ellipsis in this range:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=a498fed9095a9023c2b41ba293fab027496ab0c5&tochange=490c6510be797d46c3f20189451816fa7184fe1d (15/16 Jun 2023)
But that's not important. It's more important when the pill became too short:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=f5b526cc37742649163738dc5aaab40f9ec4159b&tochange=acbbc6a75d9aa79fa8639829f1c0ace9dfd84b1a (26/27/28 March 2023).
But as per comment 9, this is more likely a rendering issue.

It's evanescent alright and not even in the same place necessarily - so I tried on 128.5.2esr (32 bit) and I clicked on two different emails from the same person and got the first one WITH elipsis in the handle part of the email address and the second email it just shows up normally (see pill bug.png image)

Attached image pill bug.PNG
Attached image pill-damage.png

This just happened to me on 128.6.0 RC.

What I did that preceded the ellipsed email address mangling was:

  1. Clicking Reply to an already read message I got from MSI
  2. Deleted the @msi.com email that appears in the To: field after clicking Reply
  3. In my case, I entered abuse@msi.com and pressed Enter

Sadly, I didn't think to CTRL-SHIFT-J to see what Error Console said, if anything.

(In reply to Arthur K. (he/him) from comment #14)

Created attachment 9445249 [details]
pill-damage.png

This just happened to me on 128.6.0 RC.

What I did that preceded the ellipsed email address mangling was:

  1. Clicking Reply to an already read message I got from MSI
  2. Deleted the @msi.com email that appears in the To: field after clicking Reply
  3. In my case, I entered abuse@msi.com and pressed Enter

Sadly, I didn't think to CTRL-SHIFT-J to see what Error Console said, if anything.

Incidentally, when I tried to repro using the same exact email, it didn't work so it seems that it must be some situation that only happens on the first go around and after that it must clear some kind of state and ceases happening.

So this is using a crop=center XUL label, which is not the best tested code ever, but I suspect the issue would go away if Thunderbird used width / height to set the pill indicator image.

That explains why it only happens the first time it's loaded, because the indicator otherwise is cached.

In fact, I can repro the instability if I manually remove the src of the indicator image.

So, basically, add width: 8px here? https://searchfox.org/comm-central/rev/d898076e89dd7a0481fa9b0ad8d9348c17496b8e/mail/themes/shared/mail/messengercompose.css#1188

Flags: needinfo?(emilio) → needinfo?(richard.marti)
Assignee: nobody → richard.marti
Status: NEW → ASSIGNED

Yes, works for me too. Many thanks for the hint!

Flags: needinfo?(richard.marti)
Target Milestone: --- → 135 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/d679cb839763
Add on pill-indicator a initial width. r=arschmitz,emilio

Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED

Comment on attachment 9445634 [details]
Bug 1855276 - Add on pill-indicator a initial width. r=#thunderbird-front-end-reviewers

[Approval Request Comment]
User impact if declined: pill on first open can be cropped
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

Attachment #9445634 - Flags: approval-comm-esr128?
Attachment #9445634 - Flags: approval-comm-beta?

Comment on attachment 9445634 [details]
Bug 1855276 - Add on pill-indicator a initial width. r=#thunderbird-front-end-reviewers

[Triage Comment]
Approved for beta

Attachment #9445634 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9445634 [details]
Bug 1855276 - Add on pill-indicator a initial width. r=#thunderbird-front-end-reviewers

[Triage Comment]
This will be included in today's merge of cc->comm-beta.

Attachment #9445634 - Flags: approval-comm-beta+ → approval-comm-beta-
Duplicate of this bug: 1919457

Comment on attachment 9445634 [details]
Bug 1855276 - Add on pill-indicator a initial width. r=#thunderbird-front-end-reviewers

[Triage Comment]
Approved for esr128

Attachment #9445634 - Flags: approval-comm-esr128? → approval-comm-esr128+

I saw two builds but they were aborted. Is this dot release going to be built?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: