Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1017519 > unrolled thread

Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Paul Wise <pabs@debian.org> - 2020-07-11 03:50 +0200
    Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Nis Martensen <nis.martensen@web.de> - 2020-07-11 10:10 +0200
      Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Paul Wise <pabs@debian.org> - 2020-07-11 11:40 +0200
        Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Nis Martensen <nis.martensen@web.de> - 2020-07-11 12:40 +0200
          Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Simon McVittie <smcv@debian.org> - 2020-07-11 19:30 +0200
            Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Paul Wise <pabs@debian.org> - 2020-07-12 02:50 +0200
              Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Nis Martensen <nis.martensen@web.de> - 2020-07-12 10:20 +0200
              Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI Simon McVittie <smcv@debian.org> - 2020-07-12 21:30 +0200
        Re: reportbug-gtk: mua xdg-email: does not work with the GTK UI Nis Martensen <nis.martensen@web.de> - 2020-07-13 01:20 +0200

#1017519 — Bug#964846: reportbug-gtk: mua xdg-email: does not work with the GTK UI

[Multipart message — attachments visible in raw view] — view raw

Package: reportbug-gtk
Version: 7.7.0
Severity: important

When I try to use the xdg-email MUA with the reportbug GTK UI, at the
end there is a brief flash of a black screen but no MUA composer window
pops up. My default MUA on this GNOME desktop is evolution. 

$ tail -n1 .reportbugrc 
mua 'xdg-email'
$ reportbug --ui gtk
/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py:1113: Warning: The property GtkSettings:gtk-button-images is deprecated and shouldn't be used anymore. It will be removed in a future version.
  button.set_image(Gtk.Image.new_from_stock(Gtk.STOCK_INFO, Gtk.IconSize.BUTTON))
/usr/lib/python3/dist-packages/gi/overrides/Gtk.py:1632: Warning: The signal GtkWidget::visibility-notify-event is deprecated and shouldn't be used anymore. It will be removed in a future version.
  return _Gtk_main(*args, **kwargs)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (850, 'buildd-testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug-gtk depends on:
ii  gir1.2-gtk-3.0         3.24.20-1
ii  gir1.2-vte-2.91        0.60.3-1
ii  python3-gi             3.36.0-3
ii  python3-gi-cairo       3.36.0-3
ii  python3-gtkspellcheck  4.0.5-2
ii  reportbug              7.7.0

reportbug-gtk recommends no packages.

reportbug-gtk suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [next] | [standalone]

#1017535

On Sat, 11 Jul 2020 09:44:27 +0800 Paul Wise <pabs@debian.org> wrote:
> Package: reportbug-gtk
> Version: 7.7.0
> Severity: important
> 
> When I try to use the xdg-email MUA with the reportbug GTK UI, at the
> end there is a brief flash of a black screen but no MUA composer window
> pops up. My default MUA on this GNOME desktop is evolution. 

Paul, thank you for this. In fact I had the same issue when testing the
xdg-email support. Except I'm on Xfce. That's why I wrote the new
"Support for external MUAs" section in
/usr/share/doc/reportbug/README.Users.gz. Quick link:

https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/doc/README.Users#L54

Could you please test this with xdg-email and mailto URIs on the command
line to narrow down the problem and file a bug with your desktop
environment's mailto handling tool?

For Xfce the bug is in libexo-helpers, in exo-compose-email:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964799

[toc] | [prev] | [next] | [standalone]

#1017541

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2020-07-11 at 09:54 +0200, Nis Martensen wrote:

> Could you please test this with xdg-email and mailto URIs on the command
> line to narrow down the problem and file a bug with your desktop
> environment's mailto handling tool?

xdg-email works fine and xdg-open mailto: also, both in a terminal and
from the non-terminal-based GNOME command running dialog (Alt+F2). 

They also work with the reportbug text/urwid UIs, the issue only occurs
with the reportbug GTK UI for some reason.

If I add some debugging to the SystemPage execute function from the
gtk_ui.py file to print the xdg-email command that is run under a VTE
terminal. I then copied the command into a GNOME Terminal and it ran
there just fine. I then commented out the self.terminal.spawn_sync call
and the black screen in the reportbug UI stayed around instead of
closing immediately. Then I tested subprocess.run() instead of Vte
spawn_sync and it worked. Then I tested the mutt reportbug option and
it worked fine. Then I tested setting the reportbug mua option to the
evolution MUA (which xdg-email opens normally) and it worked fine. Then
I hacked the code to append "; sleep inf" to the command being run and
xdg-email worked fine. Then I tried "; sleep 0.1s" and it did not work.
0.5s does not work but 0.9s does work. So I think there is some sort of
race condition within VTE or something.

BTW, I think the GTK UI should not be running the MUAs under a VTE
terminal unless the MUA is marked as needing a terminal. Same for any
other commands it runs under a VTE terminal. For xdg-email probably
most of the commands that runs don't need a terminal.

BTW, I think that reportbug shouldn't be running commands via the shell
and definitely shouldn't be using bash even if shell really is needed.

BTW, while debugging I saw this deprecation warning:

<stdin>:1: DeprecationWarning: Vte.Terminal.spawn_sync is deprecated
https://developer.gnome.org/vte/unstable/VteTerminal.html#vte-terminal-spawn-sync

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#1017550

At this point I think we need help from someone more familiar with VTE.
Simon, do you know this stuff or do you know someone who we could ask?

On Sat, 11 Jul 2020 09:44:27 +0800 Paul Wise <pabs@debian.org> wrote:
> Package: reportbug-gtk
> Version: 7.7.0
> Severity: important
>
> When I try to use the xdg-email MUA with the reportbug GTK UI, at the
> end there is a brief flash of a black screen but no MUA composer window
> pops up. My default MUA on this GNOME desktop is evolution.

On 11.07.2020 11.34, Paul Wise wrote:
> On Sat, 2020-07-11 at 09:54 +0200, Nis Martensen wrote:
> 
>> Could you please test this with xdg-email and mailto URIs on the command
>> line to narrow down the problem and file a bug with your desktop
>> environment's mailto handling tool?
> 
> xdg-email works fine and xdg-open mailto: also, both in a terminal and
> from the non-terminal-based GNOME command running dialog (Alt+F2). 
> 
> They also work with the reportbug text/urwid UIs, the issue only occurs
> with the reportbug GTK UI for some reason.
> 
> If I add some debugging to the SystemPage execute function from the
> gtk_ui.py file to print the xdg-email command that is run under a VTE
> terminal. I then copied the command into a GNOME Terminal and it ran
> there just fine. I then commented out the self.terminal.spawn_sync call
> and the black screen in the reportbug UI stayed around instead of
> closing immediately. Then I tested subprocess.run() instead of Vte
> spawn_sync and it worked. Then I tested the mutt reportbug option and
> it worked fine. Then I tested setting the reportbug mua option to the
> evolution MUA (which xdg-email opens normally) and it worked fine. Then
> I hacked the code to append "; sleep inf" to the command being run and
> xdg-email worked fine. Then I tried "; sleep 0.1s" and it did not work.
> 0.5s does not work but 0.9s does work. So I think there is some sort of
> race condition within VTE or something.
> 
> BTW, I think the GTK UI should not be running the MUAs under a VTE
> terminal unless the MUA is marked as needing a terminal. Same for any
> other commands it runs under a VTE terminal. For xdg-email probably
> most of the commands that runs don't need a terminal.
> 
> BTW, I think that reportbug shouldn't be running commands via the shell
> and definitely shouldn't be using bash even if shell really is needed.
> 
> BTW, while debugging I saw this deprecation warning:
> 
> <stdin>:1: DeprecationWarning: Vte.Terminal.spawn_sync is deprecated
> https://developer.gnome.org/vte/unstable/VteTerminal.html#vte-terminal-spawn-sync
> 

Great debugging work. Thanks Paul!

[toc] | [prev] | [next] | [standalone]

#1017600

On Sat, 11 Jul 2020 at 12:31:44 +0200, Nis Martensen wrote:
> At this point I think we need help from someone more familiar with VTE.
> Simon, do you know this stuff or do you know someone who we could ask?

Sorry, I don't know VTE in detail. What I know about VTE is whatever I
find that I need to learn if there is a gnome-terminal regression, and
I usually forget it soon after. I'd suggest trying the GTK/GNOME team
(debian-gtk-gnome mailing list) if you need more VTE or GTK knowledge.

Someone (probably Paul Wise? I lost track of the attribution) wrote:
> > BTW, I think the GTK UI should not be running the MUAs under a VTE
> > terminal unless the MUA is marked as needing a terminal. Same for any
> > other commands it runs under a VTE terminal. For xdg-email probably
> > most of the commands that runs don't need a terminal.

I agree, and this might be a better long-term solution to the problem. If
the GTK UI is launching an email client via xdg-email, it should probably
just run the script, without doing anything special like wrapping it
in a VTE terminal. I'm using mutt.desktop, which has Terminal=true,
in a GNOME desktop, and xdg-email correctly opens a new instance of
my configured terminal (gnome-terminal) and runs mutt inside that; it's
essentially launching it like a GUI application, which happens to be
implemented by combining a terminal with a TUI. So running xdg-email in
a terminal would be redundant.

Unfortunately, xdg-email is a maze of desktop-specific code paths, all
different. I would hope that the various desktop- and toolkit-specific
code paths have approximately the same behaviour as GNOME, because they
should all be using somewhat generic "launch this app" infrastructure,
which should do the right thing... but I can't guarantee that. The
open_generic code path, used on LXQT and Enlightenment, definitely
*doesn't* do the right thing for Terminal=true MUAs (I've opened #964877).

It might be safer to build a corresponding mailto:
URI (which is desktop-agnostic and can be done in
pure Python), and then pass it to whatever is the Python
binding for g_app_info_launch_default_for_uri_async() (probably
Gio.AppInfo.launch_default_for_uri_async() or similar). That ends up doing
the same thing as the GNOME 3, Cinnamon, etc. code path in xdg-email(1),
but with 100% less shell script, using only library code that is a hard
dependency for GTK anyway. This definitely *does* handle Terminal=true
MUAs correctly. The down side of this approach is that you get #773915,
because there is no generic mechanism to choose a per-user or per-desktop
preferred terminal emulator: in Debian we do have the x-terminal-emulator
alternative, but that's Debian-specific (which makes upstreams wary), and
isn't per-user or per-desktop (so if Alice prefers GNOME, and shares a
computer with Bob who prefers KDE, there is no setting for the
x-terminal-emulator alternative that will respect both their preferences).

    smcv

[toc] | [prev] | [next] | [standalone]

#1017673

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2020-07-11 at 18:20 +0100, Simon McVittie wrote:

> Someone (probably Paul Wise? I lost track of the attribution) wrote:
> > > BTW, I think the GTK UI should not be running the MUAs under a VTE
> > > terminal unless the MUA is marked as needing a terminal. Same for any
> > > other commands it runs under a VTE terminal. For xdg-email probably
> > > most of the commands that runs don't need a terminal.

Yes, that was me.

> It might be safer to build a corresponding mailto:
> URI (which is desktop-agnostic and can be done in
> pure Python), and then pass it to whatever is the Python
> binding for g_app_info_launch_default_for_uri_async() (probably
> Gio.AppInfo.launch_default_for_uri_async() or similar).

I suggest adding that as a separate MUA to the xdg-email MUA and when
running with the reportbug GTK UI, make that new MUA the default MUA,
since people not using a terminal are even less likely to want
reportbug to submit to an MTA directly than most reportbug users.

> with 100% less shell script

Sadly, gio still uses a shell script to launch MUAs:

$ strace -f -e trace=execve gio open mailto:foo@bar.com |& grep execve | grep -v ENOENT
execve("/usr/bin/gio", ["gio", "open", "mailto:foo@bar.com"], 0x7ffcbf1e3a88 /* 96 vars */) = 0
[pid 1476622] execve("/bin/sh", ["/bin/sh", "-e", "-u", "-c", "export GIO_LAUNCHED_DESKTOP_FILE"..., "sh", "evolution", "mailto:foo@bar.com"], 0x558b45966000 /* 97 vars */) = 0
execve("/usr/bin/evolution", ["evolution", "mailto:foo@bar.com"], 0x5607406853f8 /* 98 vars */) = 0

> there is no generic mechanism to choose a per-user or per-desktop
> preferred terminal emulator

This seems like something that should get added to xdg-utils?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#1017687

On 12.07.2020 02.44, Paul Wise wrote:
> On Sat, 2020-07-11 at 18:20 +0100, Simon McVittie wrote:
>> It might be safer to build a corresponding mailto:
>> URI (which is desktop-agnostic and can be done in
>> pure Python), and then pass it to whatever is the Python
>> binding for g_app_info_launch_default_for_uri_async() (probably
>> Gio.AppInfo.launch_default_for_uri_async() or similar).
> 
> I suggest adding that as a separate MUA to the xdg-email MUA and when
> running with the reportbug GTK UI, make that new MUA the default MUA,
> since people not using a terminal are even less likely to want
> reportbug to submit to an MTA directly than most reportbug users.

The default MUA in reportbug is and will remain the built-in one,
because it most reliably avoids the practical issues involved with
passing email templates between different applications, and it also
needs zero configuration effort from users in the most common case. It
is usable even on systems where no MUA is installed at all, and does not
require a local MTA either.

External MUAs are an opt-in convenience option for users that prefer
this. The main benefit of including xdg-email among the supported MUAs
is that it provides flexible integration with further MUAs not
explicitly supported through our own code. There are no plans to make it
the default MUA for reportbug, not even specifically in the GTK ui, and
I don't think it makes sense to change that today or in the near future.

Considering the specific problem you have reported, I can reproduce this
here after switching my desktop MUA preference to evolution or sylpheed.
More on that in another mail.

[toc] | [prev] | [next] | [standalone]

#1017747

On Sun, 12 Jul 2020 at 08:44:39 +0800, Paul Wise wrote:
> On Sat, 2020-07-11 at 18:20 +0100, Simon McVittie wrote:
> > there is no generic mechanism to choose a per-user or per-desktop
> > preferred terminal emulator
> 
> This seems like something that should get added to xdg-utils?

It's something that should exist as a fd.o specification that xdg-utils,
GLib, Qt/kdelibs, etc. can all implement on the client side, and xterm,
gnome-terminal, Konsole and other terminal emulators can all implement
on the provider side. Using xdg-utils itself for the client side should
not be a requirement: libraries like GLib should be able to implement
a specification directly, like they already do for .desktop files.

https://gist.github.com/tmccombs/1642aacd4f6f8078ac0a718b72a65699 is a
recent proposal (which I have not reviewed in detail). It's perhaps made
less likely to be adopted by being more general than just terminals,
which means people reviewing and implementing it would need to have
enough time and attention to understand and implement the whole proposal,
not just the terminal parts.

https://github.com/Vladimir-csp/xdg-terminal-exec/ is an older proposal
(which I have also not reviewed in detail), which does not attempt to
go beyond terminals.

https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54 and
https://gitlab.gnome.org/GNOME/glib/-/issues/338 are among the issues
that could be resolved by desktop environments adopting one of these.

fd.o operates by consensus between major desktops, rather than by some
central authority requiring things, so none of this really means anything
without having at least a draft implementation for at least one of the
major desktop environments.

    smcv

[toc] | [prev] | [next] | [standalone]

#1017768 — Re: reportbug-gtk: mua xdg-email: does not work with the GTK UI

Dear GTK/GNOME list,

I'm looking for help with a problem in the reportbug GTK ui (bug
#964846). The GTK ui has code that uses VTE to run certain commands in a
terminal. These commands include package-specific bug scripts and
user-selected external MUAs used for bug submission. The problem is that
MUA invocation often fails if xdg-email is used.

Since the MUA selection is a user choice, the current code does not know
in advance whether the MUA needs a terminal or not, and therefore always
spawns the terminal to launch the MUA. This works fine for most MUAs,
but does not work reliably when trying to use xdg-email to launch the
user's preferred MUA. See below for the observations so far.

Is there a simple way to change the terminal-based command invocation in
reportbug's GTK ui in a way that will work reliably with xdg-email? What
changes are needed?  (Would a change from Vte.terminal.spawn_sync to
Vte.terminal.spawn_async make a difference? What exactly needs to be
changed for this?)

Or is it fine to stick with spawn_sync and we should instead try harder
to only use terminal-based command invocation if a terminal is really
needed? (That is probably a good idea anyway, but does not provide an
explanation of why the current code is failing.)

The code is here:
https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/ui/gtk_ui.py#L1467

On 11/07/2020 11:34, Paul Wise wrote:
> If I add some debugging to the SystemPage execute function from the
> gtk_ui.py file to print the xdg-email command that is run under a VTE
> terminal. I then copied the command into a GNOME Terminal and it ran
> there just fine. I then commented out the self.terminal.spawn_sync call
> and the black screen in the reportbug UI stayed around instead of
> closing immediately. Then I tested subprocess.run() instead of Vte
> spawn_sync and it worked. Then I tested the mutt reportbug option and
> it worked fine. Then I tested setting the reportbug mua option to the
> evolution MUA (which xdg-email opens normally) and it worked fine. Then
> I hacked the code to append "; sleep inf" to the command being run and
> xdg-email worked fine. Then I tried "; sleep 0.1s" and it did not work.
> 0.5s does not work but 0.9s does work. So I think there is some sort of
> race condition within VTE or something.

So I added the sleep hack (set to 3s) and tried "mua xdg-email" in a few
variants:

Desktop   preferred MUA   Result
Gnome      evolution     compose window opened, then closed within 3s
Gnome     thunderbird    compose window opened, no problem
Gnome     claws-mail     compose window opened, then closed within 3s

Then I commented out the special casing of thunderbird in the gnome3
part of xdg-email, and thunderbird starting showing the same problem:
the compose window was killed within 3 seconds.

Then I tried to reproduce in Xfce (on stable, not sid):
Xfce      evolution     compose window opened, then closed within 3s
Xfce     thunderbird    does not work due to #964799
Xfce      sylpheed      compose window opened, then closed within 3s

After fixing #964799, the problem also shows with thunderbird.


> BTW, while debugging I saw this deprecation warning:
>
> <stdin>:1: DeprecationWarning: Vte.Terminal.spawn_sync is deprecated
> https://developer.gnome.org/vte/unstable/VteTerminal.html#vte-terminal-spawn-sync

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web