1318331 - When an external application fails (terminates with a nonzero exit status), there is no feedback

Status: RESOLVED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[Vincent Lefevre]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20161115214506

Steps to reproduce:

0. Start Firefox...
1. Click on an encrypted PDF file, e.g. n2011.pdf from http://www.open-std.org/jtc1/sc22/wg14/www/docs/ (1.3 MB). The URL: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2011.pdf
2. In the dialog window that appears, choose Open with [xpdf (default)] and click on [OK].


Actual results:

Nothing seems to happen. I assume that the file was downloaded, xpdf started on it, and as xpdf doesn't support encrypted files, it simply failed. From the command line, I get:

$ xpdf n2011.pdf
Command Line Error: Incorrect password
zsh: exit 1     xpdf n2011.pdf


Expected results:

Firefox should output some feedback (with the error message from stderr if there is one).

Note: This bug is similar to bug 413608, which is against Mac OS X, but here I am under Linux. Another difference is that in bug 413608, the application didn't exist (or something like that). If it is considered that this is the same bug, this new bug could be resolved as a duplicate, but in this case, please update the platform for bug 413608 to All / All.

Comment 1

[:Paolo Amadini]

This is not the same as bug 413608 because that one refers to the case where the executable does not exist, that at least we can reliably detect for executables that are manually set by the user.

If the executable exists, as far as I know, there is little we can do because the use of return codes and stderr is not well defined for GUI applications. In fact, the target application should be a GUI application, and normally it's the application's responsibility to show a message box if there is an issue when opening the file, regardless of the return code, that may still indicate success.

For some applications the process we called may actually close immediately, and the file would be handed over to an already running process, that in turn would display the error message if there is an issue with the file.

So, depending on the case, the choice is between failing by showing nothing and failing by showing two error messages, one from the application and one from Firefox. Even worse, if the application worked correctly but it returned an "informative" non-zero error code, we would display an error message when in fact everything worked fine.

Lacking better solutions, I admit that the current behavior is sub-optimal in some cases, but acceptable, and the only alternative would be far less acceptable.

I believe other browsers would be in the same exact situation, because this is a general application interface issue.

Comment 2

[Vincent Lefevre]

(In reply to :Paolo Amadini from comment #1)
> If the executable exists, as far as I know, there is little we can do
> because the use of return codes and stderr is not well defined for GUI
> applications.

I think that there are two common behaviors in case of error:

1. The GUI application shows a message box and returns with exit status 0 (this is successful because the error has been taken into account on its side).

2. The GUI application just returns with a nonzero exit status, and in general, an error message on stderr.

> In fact, the target application should be a GUI application,
> and normally it's the application's responsibility to show a message box if
> there is an issue when opening the file, regardless of the return code, that
> may still indicate success.

But what if the GUI application can't even start, e.g. due to a missing library, so that it won't have a chance to show a message box?

> For some applications the process we called may actually close immediately,
> and the file would be handed over to an already running process, that in
> turn would display the error message if there is an issue with the file.

For such applications, this would be case (1) above (the message and the termination of the process started by Firefox occur asynchronously, but this is here not an issue).

> So, depending on the case, the choice is between failing by showing nothing
> and failing by showing two error messages, one from the application and one
> from Firefox.

In case (1), the error would be taken into account by the application only, and in case (2), it would be taken into account by Firefox only. So, there would be only one error message in both cases.

> Even worse, if the application worked correctly but it
> returned an "informative" non-zero error code, we would display an error
> message when in fact everything worked fine.

I think that this would be a bug in the application.

> Lacking better solutions, I admit that the current behavior is sub-optimal
> in some cases, but acceptable, and the only alternative would be far less
> acceptable.

There could also be a flag attached to the choice of the application, in case some application doesn't behave like in either case (1) or case (2).