Dear Maintainer,

evince hangs when I hover on a link since the last upgrade.
Clicking on the right cross does not kill it, I must xkill it.

Yours,
nicolas patrois

Dear Maintainer,

Same observation here: evince hangs and must be killed everytime I hover on a
link since last upgrade (~Feb 17).
Several additional important regressions:
- navigation in the file has become painful: 'space' no longer works, page-up
page-down frequently freeze
- no longer keeps track of zoom factor when reopening a given file / opens most
files with a non satisfying one
- thumbnails are super small (I don't care but who knows...)
- no support for synctex anymore (apparently a motivated decision, but critical
feature for me as a happy user of emacs+auctex).

I wish I could go back to the previous version as this is really painful for my
work (I did with https://snapshot.debian.org/ without any success)

Should I open new bug-reports for the various regressions?
Any hope to keep a frozen version somewhere with synctex support, as long as
new evince/pages do not support it?

Thanks for your help and efforts,
Damien

Hi,

I can reproduce this bug on Ubuntu 26.04 with:

|evince 49~alpha-2ubuntu2.1 libgtk-4-1 4.22.4+ds-0ubuntu0.1
libglib2.0-0t64 2.88.0-1ubuntu0.1|

The hang is triggered reproducibly by moving the mouse pointer over an
internal PDF link, for example a LaTeX |\cite|hyperlink : evince hangs,
no pup-up is shown.

While hung, |top -H|shows that the Evince main thread consumes
essentially 100% of one CPU, while the worker threads are idle.

Stopping it in gdb gives this backtrace for the busy main thread:

|#0 rdtsc_ordered #1 __arch_get_hw_counter #2 vdso_get_timestamp #3
do_hres #4 __cvdso_clock_gettime_common #5 __cvdso_clock_gettime_data #6
__clock_gettime #7 g_get_monotonic_time_ns #8 g_get_monotonic_time #9 
g_source_get_time #10 ... in libgtk-4.so.1 #11
g_main_context_prepare_unlocked #12 g_main_context_prepare_unlocked #13
g_main_context_iterate_unlocked #14 g_main_context_iteration #15
g_application_run #16 main|

This looks like a GTK/GLib main-loop source spinning continuously after
the link-preview popup is triggered.

BTW I also checked AppArmor because of related Evince/glycin issues: the
Evince profile includes the glycin abstraction, permits the bwrap
transition, and there are no AppArmor DENIED messages when reproducing
this hang. So this appears unrelated to the AppArmor/glycin problem that
some are experiencing,  and matches the hover-link regression described
in this bug.

Best regards,
Andrea

Hi,

regarding the SyncTeX regression mentioned by Damien: I ran into the
same problem after upgrading to Evince 49 (in Ubuntu 2604 LTS).

SyncTeX support is actually still usable. The problem is that Evince 49
changed its D-Bus namespace from |org.gnome.evince |to |org.gnome.Evince
|while AUCTeX still uses the lower-case |evince|name.

I am using AUCTeX 13.2, and the attached small changes to
|tex.el|restore both forward and inverse SyncTeX search:I rebuilt the
AUCTeX package with this patch.

After installing it, both directions work for me with Evince 49 on
Ubuntu 26.04:

  *

    Emacs/AUCTeX -> Evince: the PDF is brought to the corresponding
    position and the usual red SyncTeX highlight is displayed.

  *

    Evince -> Emacs: Ctrl-click in the PDF jumps to the corresponding
    source position.

Best regards,
Andrea

dear all

I have used an AI to prepare a patch, it seems fine to me

regards

a.