SUMMARY The open with application dialog doesn't let me choose existing application when I simply enter the path, see attached screenshot. It simply doesn't let me confirm even though this app exists. Perhaps this is related to it not finding a .desktop file, but that shouldn't matter when I clearly enter the path to an existing binary. This seems to be a problem perhaps related to, or interacting with KDE's flatpak desktop portal, since this is only broken when trying to launch a file from Brave running inside flatpak. Dolphin doesn't have this problem and there, I can set the app just fine. Is it perhaps the case that an outside application (outside of the flatpak sandbox) can only be launched if there's a .desktop file? I feel like that's not a great limitation, if the user wants to pick something else then why not? Sorry if I'm missing something obvious here. STEPS TO REPRODUCE 1. Install com.brave.Browser from flathub 2. Download some file that has no app associated with the file type, or the app associated with it is some command line app without a .desktop file 3. In the open with application dialog that should pop up, try to enter the command line app path OBSERVED RESULT It doesn't work, I can't enter the tool on the host system to be launched. EXPECTED RESULT It works, I can enter any command line tool or any app without .desktop file that I like. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: postmarketOS Edge based on Alpine Edge KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION
Thanks for the bug report. You mentioned a screenshot, but I don't see any attachments on this report. Can I ask you to attach the screenshot directly to the report? Thanks! First, yes it is expected that the "Choose Application" dialog only knows about applications installed that have a .desktop file. It won't show shells like /bin/bash, for instance. Applications having a .desktop file are how the desktop environment knows about them. There are shell apps which show up in this list, such as NeoVim and Helix (terminal apps), so this isn't limited to GUI apps. I tested this on git-master with Opera, installed from flatpak 1. Open Opera 2. Download a file (a .sh script) 3. Click on it in the Opera download menu, which brings up "Choose Application" While I can't type in '/bin/bash', I can choose Helix or NeoVim, which I have installed. This is expected. Similarly, if I type in '/bin/kate', that doesn't bring anything up, but typing in 'Kate' shows that. Testing with a downloaded .ovpn openvpn file, which has no default app set. The results are the same. To understand your use case more, I'll need some additional information. - The screenshot you mentioned - What kind of file(s) you're downloading - What application(s) you want to use to open them It's possible I'm missing a valid use case.
Also, can you try downloading the same file using a browser installed via the native packages, and see if the same behavior occurs? From what I've seen, this might not be related to the browser being installed via flatpak.
Created attachment 184444 [details] Screenshot of the "Choose application to open" dialog refusing /usr/bin/vlc and a terminal showing that program exists on the host
I can't really test it outside of flatpak, because there /usr/bin/vlc already is the default for this file type. Only with Brave inside flatpak somehow it isn't, and this dialog therefore pops up but won't let me choose /usr/bin/vlc which resides outside of the flatpak sandbox. Sorry about the screenshot, I simply forgot!
(In reply to Ellie from comment #4) > I can't really test it outside of flatpak, because there /usr/bin/vlc > already is the default for this file type. Only with Brave inside flatpak > somehow it isn't, and this dialog therefore pops up but won't let me choose > /usr/bin/vlc which resides outside of the flatpak sandbox. Thanks for clarifying and for the screenshot. I re-tested by downloading a .mid file with flatpak Opera and attempted to open it from Opera's download. It opened with VLC normally. I installed Brave via flatpak, and clicking on the .mid file also opened VLC I had the same result whether I installed Brave as a system or user flatpak. Have you installed Brave as a system flatpak or user, by chance? I also noticed that your system has Frameworks 6.16.0, and mine has 6.18.0. 6.17.0 has been released for a while, I recommend upgrading to that as soon as your distro offers it. What I think the most likely cause of the Brave flatpak not being able to access the VLC application is the flatpak permissions. Check in System Settings - Flatpak Permissions. Take a look at the xdg related ones, they should be read/write. If that doesn't solve the problem, the root problem may be the way PostmarketOS handles flatpaks and their permissions. It's worth asking their support channels. > Sorry about the screenshot, I simply forgot! No worries, it happens to us all at some point :)
If your VLC has a .destop file, you might try removing it (obviously in some way where you can restore it). I think on my system it doesn't have that file in a working state, so it's registered in "open with..." as a sort of command line app and not a regular UI app. This seems to somehow mess with how flatpak can make it available inside the sandbox.
I forgot to answer the other question: I installed Brave as a system flatpak.
Created attachment 184502 [details] Works for me This works for me when I try to open a video file on the desktop using the "Open With" dialog. See attached screenshot.
Ellie, I notice your screenshot is missing a bunch of buttons and checkboxes. Digging a bit, it seems that this stuff gets conditionally enabled if the app allows shell access. So it would appear this one does not. As such it's an app issue. As Tracey said, if you want to open this file with VLC, you'll have to make sure it has a .desktop file that's visible in all the usual places.
What I wanted to express is that I should be able to pick binaries even if it doesn't have a .desktop file. There are plenty of reasons to do so, and I commonly do that via the run in terminal option. Most command line tools have no desktop file.
I'm saying that it's up to the app whether you can or not. If the app's sandboxing settings don't permit access to command-line binaries, the dialog can't offer you the ability to use them anyway.
I still feel like something is a bit weird here. I assume "Choose application to open" is a portal dialog, and if it isn't, it probably should be. If it is, I feel like neither the permission of neither the sandboxed flatpak app nor the outside command line tool should matter, since the portal is as far as I understand meant to override permissions. Nevertheless, I'll ask about this on the forum since I might still be misunderstanding.
It's also possible there's more going on. The stack is quite deep here. I'll keep looking too.
I was wrong here; I don't think sandboxing is involved. The intentionality of this may be debateable, but it does look like a UI issue as I dig deeper.