Hi,
our app should be able to open any type of file.
Basically, it does the following:
When the user click on the name of one content downloaded the following code is executed in a child process:
xdg-open path_to_file
See the following screenshot, in this case the user clicked in the “Download the video script” link that it is a pdf file that was downloaded a few days ago. The app will execute xdg-open and the OS will open the PDF viewer (in this case the Ubuntu one):
Thanks for the example. Yes, this is the sort of thing that the on going work on the internal xdg-open will improve significantly.
The easiest way to get started would be to produce a classic snap indeed. Then you can easily migrate over to the new xdg-open support once it lands.
Thanks for your continuous support. I already created the classic snap and it is working as expected now (it opens any file via xdg-open). There are some app functionalities not working yet (like audio or video recording using web apis (our app is built on top of electron) but I’ll open a separate topic if we are not able to fix them.
For future reference if anyone else experiences the issue: If you are using electron-builder for creating a classic snap, once is created you need to edit the .yaml file and remove the desktop-launch from the command: line (and do a manual build via snapcraft snap). The reason is that classic snaps don’t support desktop-launch since it is not necessary.
This should probably be modified to “any type of file, provided the app has read access to it”.
Interestingly, xdg-desktop-portal splits this into two methods:
file:/// URIs./proc/self/fd/$fd symlink. This ensures that the app can actually open the file in question.Hi,
yes, exactly, if the app has access to the file it should be able to open
it. In our case, all the files are downloaded to the user home that is
already accessible by snap so it should be fine.
Is there a PR or 2 I can follow for progress on this?
Recently did an install of Fedora 26 and eagerly installed all of my snaps because I knew snaps are cross platform. But can’t open links from any of them. Then I remembered this discussion. It appears that snap-xdg-open isn’t available on fedora so that shim isn’t available in the stop gap like on Ubuntu.
We need to think through the safety implications of that a bit more. In particular, the application can of course read any of its content, but are we sure that it’s okay for any of the registered handlers to open the given file as well? Probably not.
That’s definitely something worth considering.
For what it is worth, xdg-desktop-portal's URL/file opener service pops up a confirmation dialog when used (along with an option to always allow the given application to open URLs/files). This also has the benefit of letting the user know which application caused the web browser to open / gain focus.
Given that we (the desktop team) want to make xdg-desktop-portal available to snaps, I do wonder whether we should consider migrating to it as the default solution. It is not at all clear that there is a need for something that will work outside of a desktop session, or what kind of semantics would make sense there. It certainly isn’t a use case that apps would expect to work outside of the sandbox.
That’s a great idea. We have the snap userd daemon work coming for a while, by @morphis, so I’d suggest not mixing that in until we get that PR landed, but would be happy to work with you to support that as the default approach next.