Bug 653249

Summary: Mutt cannot open attachments w. xdg-open
Product: [Fedora] Fedora Reporter: Dave Botsch <botsch>
Component: xdg-utilsAssignee: Rex Dieter <rdieter>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: addw, bulk, donald.a.pellegrino, egolov, ehabkost, fatkasuvayu, fedora, fge, gbenson, jwakely, michal, mlichvar, paul.destefano-redhat, pertusus, rdieter, sassmann, wls
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 571932    
Bug Blocks:    

Description Dave Botsch 2010-11-14 23:17:20 EST
Description of problem:

Fedora 13, like earlier Fedora releases, defaults to xdg-open for opening files of whatever type. xdg-open then calls the appropriate viewer to actually open the file.

In Fedora 13 (unlike 11), xdg-open forks off the viewing application and returns. This causes problems with mutt.

Mutt, upon the application called to view the attachment (by system default, xdg-open) returning, deletes the temporary file in /tmp . This essentially causes a race condition... the viewer pops up saying that no such file exists... eg:

No images found in 'file:///tmp/DSC00817.JPG'.



Version-Release number of selected component (if applicable):
mutt-1.5.21-1.fc13.x86_64
xdg-utils-1.0.2-20.20100709.fc13.noarch

How reproducible:
100% of time

Steps to Reproduce:
1. install fedora 13, including mutt and xdg-utils
2. send yourself an email with an attachment, such as a JPG file
3. open the email
4. press 'v' to view the parts of the email
5. cursor down to the JPG and press RETURN
6. xdg fires off Eye of GNome Image Viewer, which returns a File Not Found error such as:
No images found in 'file:///tmp/DSC00817.JPG'.
  
Actual results:
Image does not open in viewer


Expected results:
Image opens in external viewer
Comment 1 Miroslav Lichvar 2010-11-26 10:16:26 EST
Hm, this looks like an xdg-open problem that it doesn't wait before the file is actually opened, not sure if it's possible to fix it without reverting to the blocking behavior. Maybe this could be enabled with a command line option or an environment variable?

A workaround is to add the needsterminal flag to the mailcap entry, so mutt waits for a key press before removing the file in tmp.
Comment 2 Rex Dieter 2010-11-26 10:54:16 EST
Yeah, not all helper applications wait before returning (kde-open in particular is one example).  Not much xdg-utils can do about that.
Comment 3 Dave Botsch 2010-11-30 19:16:30 EST
Well, xdg-utils can fix xdg-open, at least.

But either xdg-open or mutt needs to be fixed. The interesting question is which.

And while one could argue that any mutt users are confortable editing the mailcap entries, one should not have to. And, does adding "needsterminal" flag to mailcap entries break anything else? More importantly, does adding this flag then break rpms from being able to update the mailcap on their own?
Comment 4 Rex Dieter 2010-12-01 08:33:39 EST
kde-open has a --tempfile option, that could be useful here.  Need to be careful about it's use though,

$ kde-open --help-kde-tempfile
...
KDE-tempfile options:
  --tempfile    The files/URLs opened by the application will be deleted after use

Perhaps we could use some sort of heuristic like "if file is in $TMPDIR or /tmp, use --tempfile"...
Comment 5 Rex Dieter 2010-12-01 08:39:09 EST
Filed bug upstream,
https://bugs.freedesktop.org/show_bug.cgi?id=32016

to help track this.
Comment 6 Rex Dieter 2010-12-01 08:40:56 EST
Speaking of heuristics, perhaps we could assume that all calls from mailcap are on temp files?
Comment 7 Miroslav Lichvar 2010-12-01 08:52:03 EST
Well, why not? :)

Is kde-open the only one which does this?
Comment 8 Rex Dieter 2010-12-01 09:05:58 EST
I don't know, there are numerous backends that xdg-open can/does use.
Comment 9 Rex Dieter 2010-12-01 09:06:34 EST
that said, kde-open is the only one with this behavior that I'm currently aware of.
Comment 10 Paul DeStefano 2011-07-22 16:00:02 EDT
Affects alpine, too.

For what it's worth, I think it is clearly xdg-open's responsibility to return either an error code or success after processing the input data.  That doesn't mean it has to wait until the chosen viewer is closed, but it can't quite before the back-end has *successfully* launched.  As it is, xdg-open returns success, even though the back-end fails immediately.
Comment 11 Ville Skyttä 2012-01-05 13:21:53 EST
*** Bug 770782 has been marked as a duplicate of this bug. ***
Comment 12 Michal Jaegermann 2012-01-05 14:10:46 EST
(In reply to comment #1)
> Hm, this looks like an xdg-open problem 

While tracking bug 770782 I tried with other "intermediary" shell scripts instead of xdg-open.  Consistently if I will append "; copiousoutput" to such mailcap entry then this works just fine; otherwise see above.  If a "handler" is called directly, say:

application/pdf; evince %s
image/*; display %s

then no problems and "; copiousoutput" is not required.
Comment 13 Rex Dieter 2012-01-05 14:24:20 EST
I seem to no longer be able to reproduce this testing with kde-open, though gvfs-open still exhibits it.

fyi, Paul, xdg-open *does* wait for the backend to return and passes back the error code given by the helper.

My small test case script:

echo 'text!' > foo.txt
kde-open foo.txt
rm -v foo.txt

seems to work for me.  replace kde-open with gvfs-open and it fails (I think I have an upstream bug open, I'll try to dig it up).

anyone seeing this on KDE ?
Comment 14 Rex Dieter 2012-01-05 14:28:23 EST
Here we go, bug #571932 , upstream 
http://bugzilla.gnome.org/show_bug.cgi?id=652262
Comment 15 Rex Dieter 2012-01-05 14:41:13 EST
I'm not sure what appending '; copiousoutput' does in the context of mailcap, but if it works, our mailcap maintainers could consider tweaking it as such as a workaround to xdg-open backend bugs (like the aforemened gvfs-open).
Comment 16 Michal Jaegermann 2012-01-05 16:27:20 EST
(In reply to comment #15)
> I'm not sure what appending '; copiousoutput' does in the context of mailcap,

That what mutt docs have to say (plus a bit more) on the subject:

   copiousoutput
          This flag tells Mutt that the command passes possibly large
          amounts of text on standard output. This causes Mutt to invoke a
          pager (either the internal pager or the external pager defined
          by the pager variable) on the output of the view command.
          Without this flag, Mutt assumes that the command is interactive.

> but if it works, our mailcap maintainers could consider tweaking it as such as
> a workaround to xdg-open backend bugs (like the aforemened gvfs-open).

It did work for me in all cases I tried even if there was no output.  It looks to  me that this "fix" is a side-effect of forcing mutt to wait.  The keyword seems to be "possbily". If this will have any effect on alpine, which somebody mentioned is affected too, I really have no idea.
Comment 17 Alain D D Williams 2012-11-08 12:04:58 EST
For what it is worth - how my solution does not always work.... so not the real fix.

I changed my .mailcap to put a 3 second delay after starting evince. This allows me to see/read the PDF ... 3 seconds is long enough for evince to get going. But if I try to print it I get empty pages - to print I need to save the attachment to a file and then view with evince. I assume that the print function involves reopening the file somewhere.

Probably similar issues with other attachment types.
Comment 18 Gris Ge 2012-11-08 21:05:00 EST
I am using a very ugly hack but a valid workaround by pointing mutt MIME to a script called mutt-open like below.
(you can change kde-open to xdg-open)

===
#!/bin/bash
NEWFILE=/tmp/mutt_bak_`basename $1`
rm ${NEWFILE} -f
cp $1 ${NEWFILE} 1>/dev/null 2>&1
kde-open ${NEWFILE}
===

It just copy the file and open the new one.

I tried hard link, but still even hard link created, the both hard link and file vanish.
Comment 19 Suvayu 2013-09-19 08:45:57 EDT
This also affects XFCE.  exo-open also returns, like gvfs-open, before
the child application is done.  On the other hand, the open_generic
option inside xdg-open does work.

Since the bugs in gvfs-open, exo-open, etc have been open for over 3
years, I would request an xdg-open work around flag.  xdg-open could
accept an option like --use-generic.  This could skip the desktop
environment check and call open_generic.  This will help many of the
affected terminal applications work around the issue.

FWIW, Emacs is also affected when calling xdg-open asynchronously.
See:

  <http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html>

If you will accept a patch, I can work on this.  Please let me know if
that is agreeable.
Comment 20 Rex Dieter 2013-09-19 09:41:59 EDT
Feature request denied, however I have an alternative suggested that can work just as well,

DE=generic xdg-open ...

should work like you want.
Comment 21 Rex Dieter 2013-09-19 09:43:38 EDT
Well, not *denied* denied, but I really don't want to add options to workaround someone else's bugs or lack of features when a workaround already exists.  Let me know if my suggestion is not workable or acceptable for whatever reason.
Comment 22 Suvayu 2013-09-19 10:17:06 EDT
I was not aware of this possibility.  This work around is much better
than new options.  Some background: I came across this issue when
users started complaining after Org mode (an Emacs major mode) started
using xdg-open.  I will discuss this work around with the devs there.

Thank you very much :).
Comment 23 Jim Haynes 2013-10-05 19:12:10 EDT
Since I'm not very smart, could you please explain how/where to apply the
workaround DE=generic xdg-open ...
Comment 24 Rex Dieter 2013-10-05 20:49:26 EDT
Jim, in this case, presumably to /etc/mailcap
Comment 25 Rex Dieter 2013-10-05 20:52:42 EDT
Or... according to 'man mailcap', you can add user-specific customizations to ~/.mailcap
Comment 26 Michal Jaegermann 2013-10-05 21:55:47 EDT
(In reply to Rex Dieter from comment #24)
> Jim, in this case, presumably to /etc/mailcap

If we are talking about mutt then, accordingly to mutt manual, mailcap is searched along mailcap_path and you can get its value by running
'mutt -nF /dev/null -Q mailcap_path'.  On Fedora this gives a default mailcap_path="~/.mailcap:/usr/share/mutt/mailcap:/etc/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap".  So mutt specific but system-wide mailcap entries with workarounds may go into /usr/share/mutt/mailcap.

That, of course, is not doing anything for other breakage, like that one from a comment 19, and every such case has to be worked around separately.  As gnome-open remains now broken for many years then likely it will stay that way.
Comment 27 Jim Haynes 2013-10-05 22:27:09 EDT
OK, that seems to work for me too - I'm using alpine as the mail program,
and making that change to /etc/mailcap allows it to work as it should.
Thanks.
Comment 28 Evgeni Golov 2015-12-22 02:45:56 EST
In 2015, this still affects me (and I am still using mutt ;))

Running Gnome3 on Fedora23, "XDG_CURRENT_DESKTOP" is set to "GNOME" and thus the code in xdg-open's detectDE() does not trigger when I set "DE". Instead setting X_C_D to X-Generic works fine for me:

  XDG_CURRENT_DESKTOP=X-Generic xdg-open …

one could also unset the var and then the DE one would win

  XDG_CURRENT_DESKTOP= DE=generic xdg-open …

Greets
Evgeni