In-call avatar decoration is sized 1:1 with the avatar (no inset like the host) and has no onError fallback #4

Closed
opened 2026-09-12 02:12:58 -04:00 by jared · 0 comments
Owner

Severity: high · Type: bug · Confidence: high

Location: src/tile/MediaView.module.css:64-80 (.lotusDecoration), src/tile/MediaView.module.css:82-90 (.avatar), src/Avatar.module.css:39-44 (avatar fills 100% of its box, aspect-ratio:1/1, border-radius circular)
src/tile/MediaView.module.css:64-79, src/tile/MediaView.tsx:145-151

Problem

.lotusDecoration and .avatar are both centered, absolutely positioned, and sized to the exact same 50cqmin × 50cqmin box. The underlying Avatar component fills 100% of that box with a circle that touches all four edges (no inset). A "frame"-style decoration image therefore has no room to extend past the avatar's edge — the ring artwork is forced into the same square the avatar circle already fully occupies, so it will visually overlap/clip against the avatar instead of surrounding it with a gap. Compare this to the host side: cinny's own AvatarDecoration.tsx (/root/code/cinny/src/app/components/avatar-decoration/AvatarDecoration.tsx) renders the same decoration images with an explicit DEFAULT_INSET = 8 px outward inset on all four sides (top:-inset, left:-inset, width:calc(100% + inset*2)…), i.e. the decoration is deliberately larger than the avatar everywhere else the roster is used. The EC in-call tile is the only place in the stack that renders it 1:1 with no outward bleed.

Related finding: .lotusDecoration uses exactly 50cqmin — the same box as .avatar. cinny renders the same asset at 100% + 2*inset (default 8px) so frame-style decorations sit around the avatar; at 1:1 they overlap and crop it, so in-call decorations look different from the ones everywhere else in the app. The EC <img> also lacks the onError hide that cinny added, so a 404 from the CDN (easy to reach given the unvalidated slug above) leaves a broken-image element over the avatar in browsers that render one for alt="".

How to trigger

Any call where the host pushes an io.lotus.decorations roster entry for a participant whose avatar is visible (video off). Reproducible statically by comparing box dimensions in the two components; visually confirms on any tile size/spotlight since the sizing is cqmin-relative and thus proportionally wrong everywhere.

Also: any participant with a frame-style decoration, camera off; compare an in-call tile with the same user's avatar in the member list.

Suggested fix

Give .lotusDecoration an outward inset matching cinny's convention, e.g. size it to ~116-125% of the avatar box (or add a fixed px/cqmin inset like cinny's 8px) instead of matching .avatar's box exactly, so the frame artwork bleeds outside the avatar circle as intended.

Also: size the overlay proportionally larger than the avatar (e.g. 62cqmin, matching cinny's inset ratio) and hide the image on error.


Filed from the September 2026 audit (branch lotus).

**Severity:** high · **Type:** bug · **Confidence:** high **Location:** `src/tile/MediaView.module.css:64-80` (`.lotusDecoration`), `src/tile/MediaView.module.css:82-90` (`.avatar`), `src/Avatar.module.css:39-44` (avatar fills 100% of its box, `aspect-ratio:1/1`, `border-radius` circular) `src/tile/MediaView.module.css:64-79`, `src/tile/MediaView.tsx:145-151` ### Problem `.lotusDecoration` and `.avatar` are both centered, absolutely positioned, and sized to the exact same `50cqmin × 50cqmin` box. The underlying `Avatar` component fills 100% of that box with a circle that touches all four edges (no inset). A "frame"-style decoration image therefore has no room to extend past the avatar's edge — the ring artwork is forced into the same square the avatar circle already fully occupies, so it will visually overlap/clip against the avatar instead of surrounding it with a gap. Compare this to the host side: cinny's own `AvatarDecoration.tsx` (`/root/code/cinny/src/app/components/avatar-decoration/AvatarDecoration.tsx`) renders the *same* decoration images with an explicit `DEFAULT_INSET = 8` px outward inset on all four sides (`top:-inset, left:-inset, width:calc(100% + inset*2)…`), i.e. the decoration is deliberately larger than the avatar everywhere else the roster is used. The EC in-call tile is the only place in the stack that renders it 1:1 with no outward bleed. **Related finding:** `.lotusDecoration` uses exactly `50cqmin` — the same box as `.avatar`. cinny renders the same asset at `100% + 2*inset` (default 8px) so frame-style decorations sit *around* the avatar; at 1:1 they overlap and crop it, so in-call decorations look different from the ones everywhere else in the app. The EC `<img>` also lacks the `onError` hide that cinny added, so a 404 from the CDN (easy to reach given the unvalidated slug above) leaves a broken-image element over the avatar in browsers that render one for `alt=""`. ### How to trigger Any call where the host pushes an `io.lotus.decorations` roster entry for a participant whose avatar is visible (video off). Reproducible statically by comparing box dimensions in the two components; visually confirms on any tile size/spotlight since the sizing is `cqmin`-relative and thus proportionally wrong everywhere. Also: any participant with a frame-style decoration, camera off; compare an in-call tile with the same user's avatar in the member list. ### Suggested fix Give `.lotusDecoration` an outward inset matching cinny's convention, e.g. size it to `~116-125%` of the avatar box (or add a fixed px/`cqmin` inset like cinny's 8px) instead of matching `.avatar`'s box exactly, so the frame artwork bleeds outside the avatar circle as intended. Also: size the overlay proportionally larger than the avatar (e.g. `62cqmin`, matching cinny's inset ratio) and hide the image on `error`. --- _Filed from the September 2026 audit (branch `lotus`)._
jared added this to the EC fork audit 2026-09 · High milestone 2026-09-12 02:12:58 -04:00
jared added the bugpriority: higharea: decorations labels 2026-09-12 02:12:58 -04:00
jared self-assigned this 2026-09-12 02:12:58 -04:00
jared closed this issue 2026-09-13 01:22:51 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
2026-10-14
Dependencies

No dependencies set.

Reference: LotusGuild/element-call#4