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

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

Abierto
  • ¿Algo no está bien?
#168 1 comentario 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
linux, tauri, typescript
Área
backend, desktop

Línea de trabajo

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.

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

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
10
Forks
2
Merge medio
3 h 55 min
PR fusionados (30 d)
92

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 egdev6/quorb

Todos los issues de egdev6/quorb

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.