Orphaned event (EventQueue.dummyRunnable) in an eventQueue will break waitForIdle.
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- java
- Área
- desktop, testing-qa
Línea de trabajo
Comienza con BasicRobot.waitForIdle y su gestión de windowMonitor.allEventQueues(), y después inspecciona el comportamiento de push/pop de java.awt.EventQueue en torno al reproductor proporcionado. Ejecuta el ejemplo con un JFrame oculto y una EventQueue personalizada; el trabajo está terminado cuando waitForIdle retorna de inmediato sin tratar una cola huérfana o dummyRunnable como trabajo pendiente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I've seen a sporadic failure where waitForIdle gets into a state where it times out after 10 seconds. The application is actually idle when this happens. This causes a lot of grief for us because it makes all the test run at a snails pace (20 minutes instead of 20 seconds).
2 important conditions for this failure:
- install a custom eventQueue via Toolkit.getDefaultToolkit().getSystemEventQueue().push()
- create and hide a Window first. (this is a splash screen in our real app).
After a lot of debugging by adding logs to BasicRobot waitForIdle, I manage to catch it where the custom event queue was empty, but it was waiting for a java.awt.EventQueue to drain. It contained an InvocationEvent with this runnable. "runnable=java.awt.EventQueue$1@2d1630f3". Looking into that lead me to the first anonymous class in EventQueue, which is the member variable "dummyRunnable". That dummyRunnable is used in push/pop to wake up the EDT.
I theorized that if the EDT was already awake when the new Queue was pushed, then that event could be left.
That didn't fail initially when I only had 1 window and tried the push from within an InvokeAndWait. I then expanded the test to create a window, hide it, push a new queue and then wait.
That reproduces the failure. Simple test case below. I think that the first queue (for the hidden window?) is really dead? maybe it should be removed from the "windowMonitor.allEventQueues()" in BasicRobot? I got this far, and now I'm at a loss as to how to proceed.
package ajs.eq.fail;
import java.awt.EventQueue;
import java.awt.Toolkit;
import java.lang.reflect.InvocationTargetException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;
import org.assertj.swing.core.BasicRobot;
public class AjsEqFail {
private final static EventQueue myQueue = new EventQueue() {
};
public static void main(String[] args) {
BasicRobot r = (BasicRobot) BasicRobot.robotWithCurrentAwtHierarchy();
r.settings().simpleWaitForIdle(false);
final JFrame f = new JFrame();
f.setBounds(10,10,300,300);
f.setVisible(true);
r.waitForIdle();
System.out.println("waited");
try {
SwingUtilities.invokeAndWait(new Runnable() {
@Override
public void run() {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
System.out.println("Hi3");
}
});
System.out.println("Hi1");
f.setVisible(false);
Toolkit.getDefaultToolkit().getSystemEventQueue().push(myQueue);
JFrame f2 = new JFrame();
f2.setVisible(true);
f2.setBounds(10,10,300,300);
System.out.println("Hi2");
}
});
} catch (InterruptedException ex) {
Logger.getLogger(AjsEqFail.class.getName()).log(Level.SEVERE, null, ex);
} catch (InvocationTargetException ex) {
Logger.getLogger(AjsEqFail.class.getName()).log(Level.SEVERE, null, ex);
}
r.waitForIdle(); //<-------------this times eventually (30 seconds?) but should be immediate.
System.out.println("waited2");
}
}
- Lenguaje dominante
- Java
- Estrellas
- 121
- Forks
- 52
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de assertj/assertj-swing
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
assertj/assertj-swing#279 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 48/100
assertj/assertj-swing#278 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
assertj/assertj-swing#276 · 1 comentario ·
-
Update unit test to avoid deprecated `ExpectedException.none()` by using `Assert.assertThrows()` Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
assertj/assertj-swing#275 ·
-
how to test when headless? Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
assertj/assertj-swing#277 · 1 comentario ·
Todos los issues de assertj/assertj-swing
Issues similares
-
certification
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Abiertobug ecr
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Needs: Triage Type: Feature request
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
github/copilot-sdk#2760 ·