On Sat, Jul 04, 2020 at 10:55:35PM +0200, Landry Breuil wrote: Hello Landry,
> 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 don't seem able to get this to work (at least with 78.0.2 in ports). When I click on (say) a PDF, I get the "what should Firefox do with this file" dialogue box rather than opening with xdg-mime. If I try browsing the file system then, even with mupdf added to unveil.main, it doesn't seem to "see" the mupdf binary, so I can't select it (but I can select Bulk Rename, Firefox, or Thunderbird?!). Either way, it doesn't seem to be firing up xdg-mime. This seems to happen with my existing FF profile and with an entirely new profile. I suspect I'm doing something very stupid here, so please feel free to point me in the right direction! Laurie
