Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#372 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
43/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
c, linux
Domínio
backend, desktop

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
C
Estrelas
10
Forks
8
Merge médio
57min
PRs com merge (30d)
2

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de FriendsofECCE/ECCE

Todas as issues de FriendsofECCE/ECCE

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.