Firefox & Ellipsis

Code
February 21, 2024

Yesterday at work I got what initially seemed be a simple bug report concerning text-overflow: ellipsis in Firefox. When a flex container (in our particular case inline-flex) contains a child that hides the overflow and uses aforementioned truncation strategy, Firefox seems to identify the need for showing the ellipsis even when there is no reason to do so. Digging deeper, I concluded there is no easy fix in sight, instead I need to file a bug report.

When doing something like this, to make things easier for browser makers, you first look through existing bug tickets to see if this has already been reported. After that, ideally you replicate the issue in a simple HTML file, and wittle away everything that has nothing to do with the problem.

This made the whole endeavour quite complex, given how random the issue is. I ended up using the character “i” repeatedly, until the issue kicks in. Then I used the same text, one time with one character added, one time one removed. The bug only appears at a certain sweat spot. But many times over, try adding more i’s until the issue appears again. And the font being used makes a difference too. (Side note: The bug report I got at work obviously used proper English text, so this can be reproduced with actual words.) What seems to be important is the presense of at least two flex children, the grandchild with text-overflow being in one of them.

Testing with Firefox version 122, I’ve seen the incorrect text-overflow on Mac and Windows, initially Linux Mint seemed to be void of the issue. At that point I’ve always used the system’s default sans-serif font. However, once I’ve thrown a web font into the mix, Firefox on Linux has the same problem:

The test file shown in Firefox on Linux, the system font does not cause the issue, whereas the web font “Inter” does.

Looking at the CodePen I’ve created in Chromium and Safari, they never truncate, so one more reason to think this is a Firefox issue. Which is why I’ve submitted bug ticket #1881220.

Showcase

Visit CodePen to see this example in action.

Comments

Matthias Zöchling wrote on February 20, 2024 at 11:21

Hello Firefox users, can you confirm (or provide other information to) a #CSS text-overflow issue I’ve encountered. Thanks in advance.
cssence.com/2024/firefox-text-overflow-issue

Šime Vidas wrote on February 28, 2024 at 01:30

In reply to: @CSSence@mas.to.

So when you remove display: inline-flex from .child, the issue goes away, and nothing else changes. Is this declaration really needed?

Matthias Zöchling wrote on February 28, 2024 at 07:12

In reply to: @simevidas@mastodon.social.

Thanks for taking the time to investigate, I’ll take a look later at work.

Additionally, the bug has already been marked as ‘fixed’ in Firefox.

Matthias Zöchling wrote on February 28, 2024 at 09:20

Regarding removing inline-flex on the second child, yes and no.

For those who are interested, some context: This is about a SplitButton React component that contains two Button components, that is why both are inline-flex. I could change the second one in the way @simevidas@mastodon.social suggested, but as said, in the bug I’ve filed you’ll see that Mozilla is providing a fix.

Matthias Zöchling wrote on February 29, 2024 at 10:10

Important update: I was made aware that this breaks in other browsers too, when zoom level is below or above 100%.

I then realized a way to fix it is to use inline-grid instead of inline-flex on the .parent, adding grid-template-columns: 1fr 2.75rem. This removes the need for the problematic calc() statement on the first child.

Join the conversation

Have your say on Mastodon, or reply on Twitter/X.