Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: ComposerBanner's `+ :has()` variant makes banner changes restyle the whole page on every thread switch

Open Beginner friendly
  • Is something wrong?
#13,851 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
tailwindcss, typescript
Domain
frontend, performance

Research direction

Start in apps/web/src/components/chat/ComposerBanner.tsx at line 114 and compare the emitted selector with the minimal Chromium reproduction in the issue. Verify the change with the listed selector-equivalence cases and a Performance trace while toggling the banner or switching threads. Done means the banner styling remains equivalent while broad style invalidation is reduced.

Written by the indexing model from the issue text.

Description

needs more info via-triage
Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/web

Steps to reproduce
  1. Build main (measured at 95030dc674) and open the web app in Chromium with a populated sidebar.
  2. Record a DevTools Performance trace while switching between threads.
  3. Look at the "Recalculate Style" events during each switch.

The minimal reproduction below needs no T3 Code. Open it in Chromium, record a Performance trace, and click the button:

<!doctype html>
<style>
  /* ComposerBanner.tsx:114, as Tailwind compiles it */
  .X + :has([data-chat-composer-form]) [data-chat-composer-form] > [data-slot=composer-banner-attachment]:first-child [data-composer-banner-surface=attached]::before { border-radius: 0 }
  /* any group-has-* utility; its group does not even need to be on the page */
  :is(:where(.group\/surface):has([data-banner=attached]) *) { box-shadow: none }
</style>
<button id="toggle">toggle banner</button>
<div id="list"></div>
<div id="stack"><div id="banner" class="X">banner</div><div><form data-chat-composer-form><div data-slot="composer-banner-attachment"><div data-composer-banner-surface="attached"></div></div></form></div></div>
<script>
  document.getElementById("list").innerHTML = "<div><span>row</span></div>".repeat(1500);
  const stack = document.getElementById("stack");
  const banner = document.getElementById("banner");
  document.getElementById("toggle").onclick = () => (banner.isConnected ? banner.remove() : stack.prepend(banner));
</script>
Expected behavior

Adding or removing a banner restyles the banner's neighbourhood, as it does when either rule is present alone.

Actual behavior

The Tailwind arbitrary variant in apps/web/src/components/chat/ComposerBanner.tsx:114 compiles to a bare :has() after a sibling combinator:

.X + :has([data-chat-composer-form]) [data-chat-composer-form] > [data-slot=composer-banner-attachment]:first-child [data-composer-banner-surface=attached]::before

When a group-has-* utility is in the same stylesheet (main ships many), adding or removing a sibling in that area makes Chromium restyle almost the whole document. The reproduction above, 20 banner toggles, counted with the trace's UpdateLayoutTree.elementCount:

Stylesheet in the reproduction Elements restyled per banner toggle (of 3,013)
no :has() rules 1
group-has rule only 1
ComposerBanner rule only 6
both, as in the file above 2,861
both, with the suggested rewrite below 6

The group-has rule's group element is not on the page at all; the rule only has to be in the stylesheet.

A thread switch adds and removes these siblings, so every switch pays for it. Measured on a main build (95030dc674, default settings), 13 scripted thread switches in headless Chromium, three rounds each:

As shipped Only the two ComposerBanner rules rewritten
Recalcs touching ≥1,000 elements 17 1
Elements restyled 32.3k 12.4k (−62%)
Style recalculation time 315 ms 156 ms (−50%)
Main thread blocked in long tasks, rapid switching 728 ms 461 ms (−37%)
Click → next paint, p50 74 ms 59 ms
Keydown → next paint, p95 54–64 ms 25–26 ms

The element counts come from Chromium's own trace and do not depend on machine load; they repeated exactly across rounds.

Suggested fix: remove the :has(), which is redundant. The rest of the selector already requires a [data-chat-composer-form] descendant of that sibling, so + * matches the same elements:

-        "[&+:has([data-chat-composer-form])_[data-chat-composer-form]>[data-slot=composer-banner-attachment]:first-child_[data-composer-banner-surface=attached]]:before:rounded-none [&+:has([data-chat-composer-form])_[data-chat-composer-form]>[data-slot=composer-banner-attachment]:first-child_[data-composer-banner-surface=attached]]:before:border-t-0",
+        "[&+*_[data-chat-composer-form]>[data-slot=composer-banner-attachment]:first-child_[data-composer-banner-surface=attached]]:before:rounded-none [&+*_[data-chat-composer-form]>[data-slot=composer-banner-attachment]:first-child_[data-composer-banner-surface=attached]]:before:border-t-0",

Checked equivalence: computed ::before styles are identical for the old and new selector with the form host after the attachment, with no attachment before it, with the attachment not first, and with the form as the sibling itself. With the rewrite, the reproduction's banner toggle restyles 6 elements instead of 2,861.

Impact

Major degradation or frequent failure

Version or commit

main @ 95030dc674 (rule introduced in #8693)

Environment

Linux, Chromium (headless, for the measurements) and the Electron desktop app. The effect is in Chromium's :has() invalidation, so every Chromium-based client is affected.

Logs or stack traces

The trace shows ScheduleStyleInvalidationTracking with changedPseudo: "has" walking every ancestor up to <html>, followed by StyleInvalidatorInvalidationTracking "Invalidation set invalidates subtree" with allDescendantsMightBeInvalid: true on each of them.

Screenshots, recordings, or supporting files

The reproduction above.

Workaround

None for users. Removing the two classes, or applying the suggested rewrite, removes the effect.

Dominant language
TypeScript
Stars
23.6k
Forks
6.1k
Avg merge
9h 26m
Merged PRs (30d)
340

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.