There are strange issues happening with /etc/mailcap handling. A quite easy way to reproduce is to try opening the same url, alterning between saving the file and launching an application. Following mailcap parsing with NSPR_LOG_MODULES=HelperAppService:5 shows that when mailcap entries are parsed right before displaying the "Opening ..." dialog, some but not all tests (when there are test=... fields in the mailcap entries) fail, which can, for example, make a different application be selected randomly.
Tracing the whole thing revealed that there is some wait() happening in a thread for something unrelated (i wonder if it's not only thread waiting) catching the SIGCHLD from the system() call child ending, instead of the wait() from the system() call itself. The wait from system() then gets a "No child process" error, which is what system() returns, making the mailcap entry marked as not matching.
Interestingly, the comment just before the system() call is // XXX this should not use system(), since that can block the UI thread!
There are strange issues happening with /etc/mailcap handling. A quite easy way to reproduce is to try opening the same url, alterning between saving the file and launching an application. Following mailcap parsing with NSPR_LOG_ MODULES= HelperAppServic e:5 shows that when mailcap entries are parsed right before displaying the "Opening ..." dialog, some but not all tests (when there are test=... fields in the mailcap entries) fail, which can, for example, make a different application be selected randomly.
Tracing the whole thing revealed that there is some wait() happening in a thread for something unrelated (i wonder if it's not only thread waiting) catching the SIGCHLD from the system() call child ending, instead of the wait() from the system() call itself. The wait from system() then gets a "No child process" error, which is what system() returns, making the mailcap entry marked as not matching.
Interestingly, the comment just before the system() call is // XXX this should not use system(), since that can block the UI thread!