2052008 - LinkedIn "Message"/"More" buttons have janky hover animation in Firefox

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Daniel Holbert [:dholbert]]

Attachment: screencast (Chrome on top, Firefox on bottom)

STR:

1. Sign in to a LinkedIn account.
2. View a person's LinkedIn profile page, e.g. https://www.linkedin.com/in/levarburton/
3. Hover the "Message" and "More" buttons and watch the animation that plays (thickening the border a bit)

EXPECTED RESULTS:
Smooth animation.

ACTUAL RESULTS:
Janky/chunky-feeling animation.

See attached screencast -- Chrome is on top (and the animation feels smooth there), Firefox is on bottom (and the animation feels jumpy/janky there).
[EDIT: there's a better screencast in comment 5, where I've slowed down the transition a bit to make it easier to see.]

I'm using Firefox 154.0a1 (2026-06-30) (64-bit) on Ubuntu 26.04

Comment 1

[Daniel Holbert [:dholbert]]

Also reproduced in Firefox release version -- 152.0.3 (64-bit) -- in a fresh profile.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reduced)

Here's a reduced testcase which reproduces the issue for me.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screencast showing janky rendering of reduced testcase in Nightly 2026-07-01

Comment 4

[Daniel Holbert [:dholbert]]

Regression range:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=39074437650a319b78daa6c74fe5feb9e3c70f15&tochange=cd6f7923ddaeca342e64f1e450152dbc3a4ea80c

--> regression from bug 2042044

I'll spin off a platform bug to track this. (Still worth keeping track of the fact that LinkedIn is impacted, so I'll keep this bug open.)

Also I think I may have mistakenly used Firefox release (which is unaffected by the bug) when recording the original screencast, and I didn't notice at first. I'll re-record that using Nightly and reattach.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast comparing Chrome (top) to Firefox (bottom) on LinkedIn, with transition-duration inflated by 10x to make the issue more obvious

Here's a screencast showing the issue on LinkedIn more clearly.

I used DevTools to increase the transition-duration from around 216ms (what LinkedIn actually uses) to 2s -- about 10x the duration -- to make the jankiness more obvious.

Here and in the reduced testcase, the primary issue (to my eye at least) is that we're growing different border-components at different times, so the animation feels out of sync.

Comment 6

[Daniel Holbert [:dholbert]]

(whoops, I thought I filled in the URL already - thanks for doing that. re-running triage tool, which bumps the score a bit due to site popularity, now that the URL is encoded here.)

Comment 7

[AutoWebCompat]

Attachment: Reproduction steps generated by autowebcompat bot

Reproduced the reported janky/out-of-sync border-thickening animation, and Chrome Mask (spoofing a Chrome UA) did NOT fix it.

Important scope note: The actual affected URL (https://www.linkedin.com/in/levarburton/) is behind a login wall — the "Message"/"More" buttons only render for signed-in users (report STR step 1). I have no LinkedIn credentials and must not bypass a login wall, so I could not reproduce on LinkedIn itself. Instead I used the report's own reduced testcase (bug attachment 9603521 [details], test.html), which reproduces the identical mechanism: a span whose inset box-shadow "border" animates from 1px to 3px spread on hover via transition: box-shadow linear 1s.

Baseline (Firefox, no mask): I slowed the transition (8s) and zoomed the page 12x to make the animation observable, then hovered and captured the element mid-transition. The inset border was clearly non-uniform at a single instant — the left edge was thicker in its upper half and stepped thinner below, the bottom edge showed a step/notch, and the corners were mismatched. A later frame showed the border uniform and thicker. This "different border components growing at different times / out of sync" is exactly the reported jankiness.

Chrome Mask test: I added the reduced testcase's host (bug2052008.bmoattachments.org) to Chrome Mask, reloaded, and confirmed navigator.userAgent contained "Chrome/150.0.0.0". Repeating the hover reproduction with the mask active produced the same stepped, out-of-sync border growth. UA spoofing did not change the rendering — consistent with the report's diagnosis that this is a Firefox platform layout regression (from bug 2042044), independent of any site-served code or User-Agent.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Comment 9

[Daniel Holbert [:dholbert]]

This was just fixed by bug 2052033. I verified the fix on the live site and the reduced testcase using a build with the fix (launched via mozregression --launch bcaaa172d733).