Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#13,851 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
88/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
tailwindcss, typescript
Área
frontend, performance

Línea de trabajo

Empieza en apps/web/src/components/chat/ComposerBanner.tsx en la línea 114 y compara el selector emitido con la reproducción mínima de Chromium del issue. Verifica el cambio con los casos de equivalencia de selectores indicados y un trace de Performance mientras alternas el banner o cambias de thread. Se considera terminado cuando el estilo del banner sigue siendo equivalente, mientras se reduce la invalidación amplia de estilos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
24k
Forks
6.3k
Merge medio
10 h 20 min
PR fusionados (30 d)
309

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.