bug(linux/wayland): ventana negra, bucle de reposicionamiento y cierre forzado del popup en 0.7.0

The report traces the regressions to createWidgetRecovery, the popup presence sampler, and the drag handle; it also points to detail_geometry::apply_native and PR #169. Read the linked pull request and inspect those entry points, especially how Wayland reports window position and handles resize. Done means the reported Wayland black window, popup closure, and frozen dragging are addressed; the report notes a remaining black-frame case on genuine visible resizes.

Pre-flight checks

• I searched existing issues and found no duplicate.
• I understand that this report enters review before implementation.

Corrección (2026-10-22): una versión anterior de este reporte atribuiría la ventana negra a noRedirectionBitmap: true. Se comprobó en tao 0.37.1 que esa opción solo existe en el backend de Windows (src/platform/windows.rs; cero ocurrencias en platform_impl/linux/ y platform_impl/wayland/), así que no causa nada en Linux y no forma parte de la solución. El origen real es el redimensionado periódico de la ventana, descrito más abajo. Se deja constancia para que nadie investigue esa vía.

What happened?

Tras actualizar a Quorb v0.7.0, en sesiones de escritorio Linux bajo Wayland (validado en KDE Plasma 6 con WebKitGTK), se observan varias regresiones:

1. Ventana negra opaca: el compositor muestra un rectángulo negro en lugar de la tira flotante.
2. Parpadeo y reubicación constante: la tira parpadea y reaparece cada pocos segundos.
3. Cierre inmediato del popup de detalle: al posar el cursor sobre un medidor, el panel se cierra casi al instante (~400 ms).
4. Arrastre congelado: al pulsar el asa, el cursor cambia a grabbing pero la ventana no se mueve.

Steps to reproduce

1. Ejecutar Quorb 0.7.0 en una sesión Wayland nativa (XDG_SESSION_TYPE=wayland).
2. Observar el fondo del widget: aparece un rectángulo negro opaco.
3. Posar el ratón sobre un orbe de cuota: el panel se cierra solo tras ~400 ms.
4. Hacer clic y arrastrar el asa: el cursor cambia a puño cerrado pero la tira no se desplaza.

Expected behavior

1. Fondo transparente sin artefactos de composición.
2. Sin reubicaciones ni parpadeos espontáneos.
3. El popup permanece abierto mientras el puntero esté encima.
4. El arrastre responde de forma fluida y se imanta al borde al soltar.

Environment

OS: Linux (KDE Plasma 6 / KWin, sesión Wayland nativa)
Toolkit: WebKitGTK (Tauri 2.12.1 / tao 0.37.1 / wry 0.57.0)
Quorb version: v0.7.0

Affected area

Application behavior

Análisis de causa raíz

1. La caja negra era el ciclo de recuperación de Windows (PR #148).
createWidgetRecovery se ejecuta cada 5 s y compara la posición esperada contra outerPosition(). En xdg-shell el compositor, por diseño de seguridad, no expone la posición absoluta de una ventana cliente, y la API devuelve (0, 0). El ciclo concluía en cada pasada que la ventana estaba descolocada y llamaba a set_widget_bounds → set_position + set_size.

Ahí está el mecanismo de la caja negra: redimensionar una superficie WebKitGTK transparente ya visible en Wayland reasigna su wl_buffer; hasta que WebKit entrega el siguiente frame, KWin compone memoria sin inicializar, que se ve como rectángulo negro. En Windows el mismo código es atómico (SetWindowPos en una sola transacción), por eso allí nunca se ve; en Linux son dos peticiones independientes a detail_geometry::apply_native.

La solución: acotar el ciclo de recuperación a Windows, que es el único backend donde DWM desplaza ventanas. Esto elimina la causa periódica; queda algún caso residual cuando el tamaño de la tira cambia de verdad (aparece un proveedor, se muestran los resets, cambia orbSize o el DPI).

2. Cierre inmediato del popup (PR #154).
El muestreo de presencia sondea cursorPosition() cada 400 ms porque en macOS WKWebView deja de emitir mouseleave. El comentario del PR asumía que en Wayland esa llamada fallaría y «degradaría en silencio», pero en WebKitGTK no falla: devuelve (0, 0). La comparación geométrica concluía en cada muestra que el cursor estaba fuera del panel y disparaba el cierre.

Solución: acotar el muestreo a macOS. En Linux el cierre vuelve a depender de los eventos mouseleave/mouseenter del DOM, que sí funcionan.

3. Arrastre congelado.
El asa inicializaba d.start únicamente con outerPosition(), que en Wayland devuelve (0, 0); el resto de la aritmética de movimiento quedaba anclada a un origen falso, así que la ventana no se desplazaba aunque el gesto se registrara.

Solución: arrancar desde los bounds que el widget ya conoce en memoria y calcular el movimiento sobre el desplazamiento del puntero; al soltar, el imán usa el desplazamiento acumulado cuando el compositor no reporta posición.

4. Ergonomía de apertura.
OPEN_DELAY de 90 ms a 350 ms (a 90 ms el detalle se disparaba al recorrer la tira con el cursor) y apertura/cierre por clic directo en el orbe.

Hay un PR con el arreglo en 👉 #169.

Nota sobre el residuo

Queda un caso acotado: si la tira cambia de tamaño con la ventana visible (un proveedor nuevo, los chips de reset, orbSize, un cambio de DPI), en Wayland puede aparecer un rectángulo negro hasta el siguiente frame. La causa es la misma —redimensionar una superficie transparente visible— pero el disparador es legítimo. La mitigación posible es redimensionar con la ventana oculta, o evitar el redimensionado en Linux; queda abierto a criterio del mantenedor porque tiene coste en UX.