Si estás leyendo esto, probablemente tienes el mismo bug que nosotros: los popups de TinyMCE (menús de toolbar, tooltips, selectores de fuente, color, bloques) aparecen desplazados hacia abajo, y el desplazamiento es proporcional a cuánto scroll has hecho en la página. Cuanto más bajas, más lejos aparece el popup de donde debería estar.

Nos costó 9 intentos resolverlo. Este artículo documenta cada uno para que no tengas que repetir el mismo camino.

El bug: popups de TinyMCE desplazados proporcionalmente al scroll

Elementos afectados: cualquier popup o tooltip de TinyMCE. Los menús desplegables de la toolbar, tooltips de los botones, selectores de fuente, bloques, color, y plugins custom (en nuestro caso, un plugin de AI Writer). Todos se desplazan hacia abajo exactamente la misma cantidad de píxeles que has scrolleado.

Si estás en el top de la página: todo perfecto. Si has scrolleado 500px: el popup aparece 500px más abajo de donde debería. El patrón es lineal y predecible, lo que apunta directamente a un problema de cálculo de coordenadas, no a un bug de renderizado aleatorio.

document.querySelector('.content').scrollTop  // → Valor del scroll real
window.scrollY                                 // → Siempre 0 (este es el problema)

La causa raíz (por qué getBoundingClientRect miente)

El bug está en la intersección de tres sistemas que no conocen la existencia del otro.

La arquitectura de AdminKit

AdminKit (y muchos frameworks CSS de admin panels) usa un patrón SPA donde el body no scrollea. El scroll lo hace un contenedor interno:

body                        ← overflow: hidden (NO scrollea → window.scrollY = 0)
  └── .wrapper               ← flex horizontal
       ├── #sidebar           ← sidebar fija
       └── .main              ← overflow: hidden
            └── .content      ← overflow-y: auto → ESTE scrollea

Cómo calcula TinyMCE la posición de sus popups

TinyMCE hace lo que haría cualquier librería razonable:

1. Llama a getBoundingClientRect() del botón para obtener sus coordenadas relativas al viewport.
2. Suma window.scrollY para convertir a coordenadas absolutas del documento.
3. Coloca el popup con position: absolute en el body.

El conflicto

Como window.scrollY es siempre 0 (el body no scrollea), TinyMCE no compensa nada por el scroll. Pero el popup está posicionado con position: absolute relativo al body, mientras que el botón que lo dispara está dentro de .content que sí ha scrolleado.

Resultado: getBoundingClientRect() devuelve la posición correcta del botón en el viewport, pero cuando TinyMCE convierte eso a posición absoluta, la ecuación rect.top + window.scrollY da un resultado incorrecto porque window.scrollY = 0 cuando el scroll real está en otro sitio.

TinyMCE y AdminKit hablan idiomas de coordenadas diferentes. El popup se coloca donde estaría el botón si no hubiese scroll, no donde está realmente.

Las 9 soluciones que probamos (y por qué no funcionaron)

La solución que funcionó: cambiar quién scrollea

Después de 9 intentos, la conclusión fue clara: no se puede parchear un conflicto de sistemas de coordenadas con JavaScript. Si dos sistemas (AdminKit y TinyMCE) asumen cosas diferentes sobre quién scrollea, la única solución limpia es alinear las asunciones.

La solución: hacer que el body sea el que scrollee, no .content.

html, body { overflow: hidden; }
.main      { overflow: hidden; }
.content   { overflow-y: auto; }    /* ← ESTE scrollea */
/* window.scrollY = 0 siempre → TinyMCE se confunde */

html, body { height: 100%; margin: 0; }
.main      { /* sin overflow forzado */ }
.content   { /* sin overflow-y: auto */ }
/* El BODY scrollea → window.scrollY refleja el scroll real */

Y el sidebar con position: sticky; height: 100vh; para que se quede fijo mientras el body scrollea.

Por qué funciona

Cuando el body es el que scrollea, todos los cálculos de TinyMCE son correctos:

1. window.scrollY tiene el valor real del scroll.
2. getBoundingClientRect().top devuelve la posición relativa al viewport.
3. rect.top + window.scrollY = posición absoluta correcta en el documento.
4. El popup con position: absolute en el body se coloca exactamente donde debe.

TinyMCE y el body hablan el mismo idioma de coordenadas. No hay parche, no hay hack, no hay monkey-patch. Solo dos sistemas que por fin están de acuerdo en cómo funciona el scroll.

Cómo implementar el fix paso a paso

Los cambios necesarios en un proyecto Laravel con AdminKit y TinyMCE:

1. CSS del layout (app.blade.php)

/* Quitar overflow: hidden del body y de .main */
html, body {
    height: 100%;
    margin: 0;
    /* NO poner overflow: hidden */
}

.main {
    /* quitar overflow: hidden si lo tiene */
}

.content {
    /* quitar overflow-y: auto */
    /* el body hará el scroll */
}

/* Sidebar fijo */
#sidebar, .sidebar {
    position: sticky;
    top: 0;
    height: 100vh;
    overflow-y: auto;
}

2. TinyMCE config (parciales _tinymce.blade.php)

// QUITAR estas opciones que ya no necesitas:
// ui_mode: 'split',        ← quitar
// ui_container: 'body',    ← quitar

// QUITAR todo el JS de monkey-patch:
// updateTinyAuxOffset      ← quitar
// ensureTinyAuxLayerOnBody ← quitar
// startTinyAuxObserver     ← quitar
// fixTinyMCEPopups         ← quitar
// translateY hacks         ← quitar
// MutationObserver hacks   ← quitar

3. Testing

Verificar después del cambio:

• Scroll de la página funciona correctamente.
• Sidebar se mantiene fija al scrollear.
• Popups de TinyMCE aparecen debajo del botón que los dispara, sin importar la posición de scroll.
• Tooltips de la toolbar aparecen correctamente.
• El resto del panel de admin funciona (formularios, tablas, navegación).

La lección para otros desarrolladores

Si tienes un layout tipo SPA donde un contenedor interno scrollea (no el body) y usas una librería de terceros que asume que window.scrollY refleja el scroll real, vas a tener este tipo de bug. No solo con TinyMCE: cualquier librería que posicione popups, tooltips o dropdowns con position: absolute en el body y use getBoundingClientRect() + window.scrollY se va a confundir.

La tentación es parchear con JavaScript. No funciona a largo plazo. La librería tiene sus propios ciclos de renderizado que van a competir con tu parche. El resultado son parpadeos, edge cases y código frágil que se rompe con cada actualización.

La solución limpia es siempre la misma: alinear las asunciones. Si la librería asume que el body scrollea, haz que el body scrollee. Si no puedes cambiar el layout, entonces necesitas una librería que soporte tu patrón de scroll (o contribuir un fix upstream para que lo soporte).