Hi, On Sat, Jul 04, 2020 at 10:55:35PM +0200, Landry Breuil wrote: > I've looked a bit at this, and its a bit more complicated than expected, as > spawning xdg-open to find the configured mime handler also calls the > same codepath, that now uses /bin/sh (in > https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gdesktopappinfo.c#L2695) > > So my idea it to avoid relying on all the glib > g_app_info_launch_something that end up calling > g_desktop_app_info_launch_uris() (which would require adding /bin/sh to > unveil.main), and instead fix all the 3 callers for g_app_info_launch* > (ie https://searchfox.org/mozilla-central/search?q=g_app_info_launch&path=) > to do a (simpler?) thing: > - in nsGIOService::GetAppForMimeType(), instead of calling xdg-open to > find the handler (which wouldnt work anymore since > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1362) get the > mimetype handler via g_app_info_get_default_for_type() (at that point, i > think that works since /usr/local/share is unveiled, all .desktop files > are available), check that it exists in the PATH via > g_find_program_in_path() (ie it's properly unveiled), if not issue a > loud g_warning on stderr. > > - in all the g_app_info_launch* callers (ie mainly > nsGIOMimeApp::LaunchWithURI(), but also sometimes > nsGIOService::ShowURIForInput(), havent found which codepath leads to > which), replace the call by: > - if we have an URI, find its mimetype via g_content_type_guess() and > get the corresponding handler via g_app_info_get_default_for_type() > - find the handler executable via g_app_info_get_executable() > - call it via g_spawn_async() (using G_SPAWN_SEARCH_PATH will look it up in > the > path) > > here, with those handlers added to unveil.main: > /usr/local/bin/mupdf rx > /usr/local/bin/xarchive rx > /usr/local/bin/xarchiver rx > /usr/local/bin/mplayer rx > /usr/local/bin/parole rx > > clicking on a pdf or tar.gz or zip or flv link directly opens (after > downloading it to /tmp/mozilla_landry0/) the corresponding file in its > default handler configured via xdg-mime. > > $xdg-mime query default application/x-compressed-tar > xarchive.desktop > $xdg-mime query default video/mp4 > org.xfce.Parole.desktop > $xdg-mime query default application/pdf > mupdf.desktop > > Not sure that's the right way to handle this, nor if it causes other > issues i havent thought about but it works for me using 79.0b3. > > To test, drop the attached patch in > /usr/ports/www/mozilla-firefox/patches/patch-toolkit_system_gnome_nsGIOService_cpp > and use G_MESSAGES_DEBUG=all firefox if you want to see the g_debug() > msgs.
I gave this a spin on my system. If I add the appropriate binaries to unveil.main it seems to work fine, but if for instance /usr/local/bin/evince is not present in unveil.main even though it is the default for a PDF file, the following happens: (firefox:35438): GLib-GIO-CRITICAL **: 17:22:52.848: g_app_info_get_executable: assertion 'G_IS_APP_INFO (appinfo)' failed ** Message: 17:22:52.848: ShowURIForInput: spawning (null) /tmp/mozilla_caspar0/somefile.pdf for file:///tmp/mozilla_caspar0/somefile.pdf (content type application/pdf) Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Segmentation fault (core dumped) I assume the problem is that g_app_info_get_executable() returned NULL. Thanks, Caspar Schutijser
