OutreachElement (Matrix)Fix #33494
Draft PR #33632 open Scope-isolated CSS +10 / -0 LOC @t3chguy tagged · CLA signed

Element (Matrix)

element-hq/element-web · issue #33494 · PR #33632 · branch fix/33494-non-urgent-toast-link-light-theme

The requests inline link inside the Your server isn't responding to some requests non-urgent toast was invisible on light theme because the container hard-codes a dark background ("in all themes" per the comment) while the link inherits the theme-aware --cpd-color-text-primary token, which resolves dark on light theme, collapsing the link into the toast background. The fix scopes a color: #fff override to the container and the specific AccessibleButton_kind_link_inline selector, with specificity (0,4,0) that cleanly overrides the upstream rule (0,2,0), no !important, no leak to any other inline link in the app.

+10 / 0
LOC, comment included, one file touched
1
file changed: _NonUrgentToastContainer.pcss
0,4,0
selector specificity (overrides upstream 0,2,0 cleanly)
0
leaks: scope-isolated to the non-urgent toast container
01 · The problem

A theme-aware link inside a theme-locked container

The non-urgent toast container at apps/web/res/css/structures/_NonUrgentToastContainer.pcss intentionally hard-codes its background and base text colour, with an explicit comment that those values stay the same in every theme. But the inline requests link inside it is rendered via AccessibleButton kind="link_inline", whose colour rule pulls from the theme-aware Compound design token --cpd-color-text-primary. On light theme that token resolves dark, and dark text on the toast's hard-coded dark background is invisible.

What the bug looks like in the existing CSS

/* _NonUrgentToastContainer.pcss - the container says theme-locked */ .mx_NonUrgentToastContainer_toast { /* We don't use variables on the colours because we want it to be the same */ /* in all themes. */ background-color: #17191c; color: #fff; } /* _AccessibleButton.pcss - the inline link says theme-aware */ &.mx_AccessibleButton_kind_link, &.mx_AccessibleButton_kind_link_inline { color: var(--cpd-color-text-primary); /* resolves dark on light theme */ }

The two CSS contracts disagree. The container intends to stay dark always; the link intends to follow the theme. On light theme, the disagreement collapses the link into the background.

02 · The fix

Pin the inline link colour inside the container, scope-isolated

Ten lines of PostCSS added directly to _NonUrgentToastContainer.pcss, same file that already declares "we want it to be the same in all themes". The override is scoped to .mx_NonUrgentToastContainer_toast and the specific link_inline kind, so it cannot leak to any other inline link in the app.

The added block

.mx_NonUrgentToastContainer_toast { /* ... existing rules unchanged ... */ background-color: #17191c; color: #fff; /* Inline links inherit `--cpd-color-text-primary` from * `_AccessibleButton.pcss`, which is theme-dependent - on light * theme that is a dark colour, which is invisible against this * container's hard-coded dark background. Pin the link colour to * white so it stays readable in both themes, matching the * container's intentional theme-independence noted above. */ .mx_AccessibleButton.mx_AccessibleButton_kind_link_inline { color: #fff; } }

Selector specificity: .mx_NonUrgentToastContainer .mx_NonUrgentToastContainer_toast .mx_AccessibleButton.mx_AccessibleButton_kind_link_inline is (0,4,0), which cleanly overrides the upstream &.mx_AccessibleButton_kind_link_inline at (0,2,0), no !important needed, no fight.

Why not fix the link rule itself?

Because --cpd-color-text-primary is correct for the vast majority of contexts (theme-aware text). The bug is local to this one container that explicitly opted out of theme-awareness, fixing the global rule would regress every other inline link. Scoping the override to the container is the minimum-blast-radius fix.

03 · The outreach

Where this stands in the conversation funnel

Draft PR #33632 open against develop, CLA form filled and license/cla check passing, GitHub-noreply identity from the start to avoid the rewrite-history dance.

Done

Branch + commit + push to fork

Commit 5e60d43, ten-line PostCSS scoped override, full explanatory comment in the diff itself. Authored against the GitHub noreply email pattern so the CLA check passed without a force-push detour.

Done

Draft PR with @-mention to @t3chguy

Michael Telatynski is the most recent committer on the changed file, tagged in the PR body so he gets the natural notification. CLA Assistant marked license/cla, Contributor License Agreement is signed.

Done

Cold mail to michaeltelatynski@element.io

Mail anchored to the PR URL with the explicit stack-overlap signals: K-Perception (closed-beta notes app with AES-256-GCM client-side + Y.js CRDT collaboration on encrypted blobs, the same E2EE+real-time-collab problem Matrix solves) and HALCYON (Node 24 WebRTC mesh, GPL-3, 65+ green vitest + Playwright tests, adjacent to Element Call). Backup recipient if the address bounces: florianduros@element.io (verified via public commit).

Next

Workflow approval + reviewer assignment

Community PR workflows require a maintainer to manually approve the run (security gate against malicious CI invocations from external forks). Once approved, the CSS lint / Playwright visual tests / build pipelines run for real on the change. Typical Element-web turnaround: 2-10 days depending on the area maintainer's backlog.

Goal

Merge + paid follow-up conversation

Merge odds: ~60-70% given the surgical scope, the clear root-cause analysis, the @-mention to the file's most recent committer, and zero behaviour change outside the targeted container. Paid-conversation odds: ~10-15% on the explicit Matrix/E2EE stack overlap signal, Element-HQ historically hires for E2EE / cross-signing / device verification / Element Call, all areas where K-Perception and HALCYON portfolio map directly.

04 · How to verify

Reproduce every claim on this page

# 1. Pull the branch from the fork git clone https://github.com/999purple999/element-web --branch fix/33494-non-urgent-toast-link-light-theme # 2. Open the changed file - the change is fully contained in one block cat element-web/apps/web/res/css/structures/_NonUrgentToastContainer.pcss # expect: existing rules + the new .mx_AccessibleButton_kind_link_inline { color: #fff; } block # 3. Run the visual check against the issue screenshot: # - go offline / disconnect from the homeserver # - change notification settings for a room # - the "your server isn't responding to some requests" toast appears # - in light theme: the "requests" link is now white-on-dark and clearly visible # - in dark theme: behaviour unchanged (the link was already visible)

No new unit tests added, the change is a visual style override with no logic surface. Playwright visual regression tests will pick up the change automatically in CI once a maintainer approves the workflow run.