Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Each window waits 25 s on the accessibility bus when the account has no desktop session (ssh -X)

Ouverte
  • Quelque chose ne va pas ?
#372 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
43/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
c, linux
Domaine
backend, desktop

Piste de recherche

Reproduce the delay on an account without a desktop session, using ssh -X or Xvfb, and trace startup to identify the blocking call; the issue does not name source files or tests to start from. The environment workarounds listed did not remove the wait, so first establish which call blocks before deciding on a fix. Done means the affected ecce startup no longer waits about 25 seconds in this scenario.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

On a machine where the user has a systemd user session (and therefore a session D-Bus) but has never had a desktop session, every GTK window of ECCE waits about 25 s before it appears. GTK registers with the accessibility bus (org.a11y.Bus, org.a11y.atspi.Registry); no reply comes, and the call ends at the D-Bus default timeout:

dbind-WARNING **: Couldn't register with accessibility bus: Did not receive a reply.

Seen on a Debian 13 host used only over ssh (2026-10-19), started with ssh -X and on Xvfb. Measured with strace: X11 connect to first data server request 25.8 s; with DBUS_SESSION_BUS_ADDRESS=disabled: 0.8 s. After one graphical login on that host the wait was gone (0.8 s). xdg-desktop-portal and xdg-desktop-portal-gtk user units were in the failed state before the login.

Who would see it: users who run ecce on a server over ssh -X, VNC or X2Go with an account that has never logged into a desktop there. Not a local desktop session; not the central-server mode where the client runs on the user's own machine.

Not yet known: which call blocks. NO_AT_BRIDGE=1, GTK_USE_PORTAL=0 and GIO_USE_VFS=local did not remove the wait in a scripted test, so the obvious environment fix is unconfirmed.

Next step: reproduce on an account without a desktop session, find the blocking call, then decide whether ecce sets something when no desktop session is present.

Related: the apps smoke check passed on Builder's 10x10 placeholder window while the main frame never appeared; it should wait for the real main window. The apps suite could also run apps under its own dbus-run-session.

Langage dominant
C
Étoiles
10
Forks
8
Merge moyen
57 min
PR mergées (30 j)
2

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de FriendsofECCE/ECCE

Toutes les issues de FriendsofECCE/ECCE

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.