url: clamp the truncated file name slice in filterURLForDisplay - #81529

What?

filterURLForDisplay() no longer returns a string far longer than the maxLength it was given.

Why?

In the branch that truncates a long file name, the head slice is:

file.slice( 0, maxLength - truncatedFile.length - 1 )

truncatedFile is always fileName.slice( -3 ) + '.' + extension — seven characters for a three-character extension. As soon as maxLength is at or below that, the second argument goes negative, and String.slice reads a negative end as an offset from the end of the string. Instead of clipping the head to nothing, it keeps nearly the whole file name:

filterURLForDisplay( 'https://example.com/averylongfilename.png', 5 );
// actual:   'averylongfilename.…ame.png'   (26 characters, for maxLength 5)
// expected: '…ame.png'

So the smaller the maxLength, the longer the output — the opposite of the function's contract. maxLength: 8 already returns '…ame.png', so that is the shortest form this branch can produce.

Callers pass maxLength to fit a URL into a fixed-width UI (LinkControl's preview, for example), so an over-long return overflows the very layout the argument exists to protect.

How?

Clamps the head slice at zero with Math.max( 0, … ). Anything that was already producing a non-negative end is unaffected — the existing maxLength: 20 test still passes unchanged.

Adds a unit test for the tiny-maxLength case, which fails on trunk with the 26-character output above.

Testing Instructions

npm run test:unit -- packages/url

Testing Instructions for Keyboard

n/a — no interaction changes.

Use of AI Tools

AI tooling (Claude Code) was used to help find this defect and draft the fix and test. I confirmed the wrong output on trunk myself, verified the test fails before the change and passes after, and take responsibility for the code in this PR.